Inside Cycloid permissions are handled by roles which are an aggregation of policies. Those roles can then be assigned to a user at the organization level as a 'default role', or at a team level to provide extra permissions to a set of users within a team.
By default, 2 roles exist:
- The organization admin one: provides a full access over an organization.
- The organization member one: provides a read-only access over an organization.
Define the scope for individual actions. Those actions can be of various type: creating a project, deleting a credential, reading roles, etc.
These policies can also be narrowed down to specific entities. So that, if you were to have multiple credentials, you could create a role containing policies only for a specific subset of credential. Thus allowing you to have a thinner control on who can do what.
If you want to target a specific Resource you can do it using the 'Specific resources'
checkbox. You can there enter the specific 'canonical' of the resource or use
* to make partial matches (e.g:
*-staging will match all the resources ending
In entities with nested children you'll also find the "Propagate" button, which allows you to spread the actions down to all nested entities. This would obviously NOT spread specific resources, as they are specific of current entity.
If you want to customize even more the policies of the role you can use the "Manual Actions" which allows to customize the policies by writing the 'Action' and the 'Resource' manually:
- 'Action': Is the Policy code, can be found by selecting a Policy (ex:
- 'Resources': The full path to the Resource (ex:
All of them can also use
*: Anything in between separator (
organization:credential:*allows all actions to credentials)
**: Anything skipping separator (
organization:**allows to do anything on the organization)
So you can create something like:
Which will allow to do any action to the credential that start with
cy- or end with
Which will allow access to any sub policy/action inside the specific
If no resource is given, then the policy will be applied to all resources within the organization
Roles represents a logical aggregation sets of policies & entities. New policies cannot be created, as they are based on the possible action within the product, but roles can.
Roles will be available at both organization & team level. Which means that if you create a "Role A", that can for example manage any project and environments, it will be possible to apply it either to a team, to increase the permissions of those team members, or at the organization level to make it their default role when logging in - assuming they are not part of some teams.
Permissions are handled in an 'incremental way', there is no forbidding rules.
Either you have a permission to do an action or you do not. If you were given in a role the possibility to read project A, and in another one project B, you will end up with the permissions to read project A and B.
A special role exists, the 'admin' one, which once given provide access to any actions on any resources within the current organization.
# Organization level
The organization role is defined upon invitation of other members, it can be
later on edited/updated by members who have access on it. To manage those members
please click on the
Members button on the left panel.
It is also possible to invite multiple members with the same role:
# Teams level
Teams are simply a gathering of people to which the same role(s) is applied.
This is meant to extend default permission of an organization member, and create logical group of people: because they work together, because there is some hierarchy, because of a temporary task to do, etc.
To create or manage teams, click on the
Teams button of the panel:
If you want to create a new team click on the
Create a new team button, or if
you want to manage an existing one, click on it:
In this silly example the 'Owl bot' account, which is admin of the organization, also gained the 'Organization Member' & 'Organization Owl' roles.