Roles
Roles are used to define the policies to be applied. A role has one or more policies.
Create role
When you create a role, you must define whether it is a role that will apply to project resources (like "Environment", "Platform access", "Registry", etc.) or to environment resources (like "Services", "Instance Pools", etc.).
To give access to a specific environment, the user needs both a "Project's role" with a rule that grants access to that environment and the appropriate environment permissions.
When you select "Environment's role", you must select the environment to which the role will apply.
Once you have chosen the type of role, you can add policies for the resources. You can specify policies on specific resources, such as "the right to read the service Wordpress".
Here are the different actions on which you can add rules:
- Read: User can read all resources of this type (or a specific resource if specified).
- Create/update: User can create resources and edit only those they created. Users can also only view their own resources. (Can be combined with another policy with the "Read" action to allow the user to see everything, but only create and edit their own resources.)
- Read/Write: User can read and update all resources and create new resources (or a specific resource if specified).
- Admin: Only available for environment resources. Allows a user to become an administrator of the environment: the user can perform any action with resources in this environment (create services, instance pools, etc.). This is useful when you don't want to create individual policies for all resources in non-production environments.
It's up to you to decide how to organize the roles and groups. You can have few roles with many rules, or very specific roles with few rules.