Permissions

Cycloid platform include a fine tune policy based permission management. Each permission can have multiple policies that define allowed actions on entities.

Permissions can be attached to roles, members, teams and API_keys. They are also scoped by organization.

note

This is a current limitation, since cycloid API tokens are scoped by organizations, you can't create an organization using the API (this includes the CLI too.).

This may evolve in the future.

Policies

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 with -staging)

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.

Manual Actions 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: organization:credential:create) 'Resources': The full path to the Resource (ex: organization:{org-canonical}:credential:{credential-canonical}) All of them can also use * or **:

: Anything in between separator (:) (ex: organization:credential: allows all actions to credentials) : Anything skipping separator (:) (ex: organization: allows to do anything on the organization) So you can create something like:

organization:credential:* => organization:{organization-canonical}:credential:cy-,organization:{organization-canonical}:credential:-staging

Which will allow to do any action to the credential that start with cy- or end with -staging

Or

organization:project:** => organization:{organization-canonical}:project:{project-canonical}:** Which will allow access to any sub policy/action inside the specific {project-canonical}.

warning

If no resource is given, then the policy will be applied to all resources within the organization

Roles

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.

Cycloid maintain a set of default roles to cover most common use cases:

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.

note

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 Organization settings menu.

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 'Cyclobot' account, which is admin of the organization, also gained the 'Organization Member' & 'Organization Owl' roles.