Role-based Access Control (RBAC)
If RBAC is not yet enabled for your installation and you would like to do so, please contact the Conveyor team (note that RBAC is an enterprise-only feature).
When Role-Based Access Control (RBAC) is enabled on your installation, you will be able to assign project roles and environment roles to Conveyor users and teams.
This can be done from the CLI or from the user interface (from a project page, an environment page or from the settings page).
See the following CLI documentation pages:
- conveyor user
- conveyor project add-user
- conveyor project remove-user
- conveyor project list-users
- conveyor environment add-user
- conveyor environment remove-user
- conveyor environment list-users
Roles
Admin role
An admin user can perform all actions available in Conveyor, on all resources (projects, environments, users, ...).
The first admin user(s) is automatically set up when a tenant has been created.
Subsequently, admin user(s) can grant roles to other users themselves through the CLI or the UI. The admin role also grants access to the Settings page in the UI, allowing to grant the admin role to other users.
Project contributor
A project contributor has the necessary rights to work on a project. The means:
- Creating build for a project using conveyor build
- Deploying project to an environment conveyor deploy
- Triggering conveyor run for a project on an environment conveyor run
- Promote project from and to environments conveyor project promote
Actions involving environments the user also needs at least environment contributor on said environment.
Project admin
A project admin has all the same permissions as a project contributor. But has the added rights to:
- Manage users and teams access on a project
- Delete the project
Environment operator
An environment operator has:
- read-only access to the environment in Conveyor
- Access to the Airflow UI of that Environment
The idea of this role is to give enough permission to follow up:
- The status of tasks in Airflow, and restart them if needed
- Look at logs of the runs of projects
Actions involving projects mean you also need at least project contributor to said project. The user can not deploy project to the environment.
Environment contributor
An environment contributor has all the access of an environment operator but also can:
- Deploy a project to an environment conveyor deploy
- Promote a project from an environment to another environment conveyor project promote
Actions involving projects mean you also need at least project contributor to said project.
Environment admin
An environment admin has all the same permissions as an environment contributor, with the extra rights to:
- Manage users on the environment
- Delete delete the environment.
Example
Consider the following 3 users and their respective roles:
| User | Admin role? | Project Roles | Environment roles |
|---|---|---|---|
| Alice | No | ProjectA, ProjectB | Env1 |
| Bob | No | ProjectC | Env2, Env3 |
| Charlie | Yes | - | - |
The following combinations of users/project/environment deployments would then be enforced:
| User | Project | Can deploy to Env1 | Can deploy to Env2 | Can deploy to Env3 |
|---|---|---|---|---|
| Alice | ProjectA |  |  | |
| Alice | ProjectB | | | |
| Alice | ProjectC | | | |
| Bob | ProjectA | | | |
| Bob | ProjectB | | | |
| Bob | ProjectC | | | |
| Charlie | ProjectA | | | |
| Charlie | ProjectB | | | |
| Charlie | ProjectC | | | |
Teams
A team is a group of users to which permissions can be assigned. The same environment and project roles described above for users are used for teams.
Membership
There are two roles a member of a team can have:
- Admin: Team administrators can invite more users to a team, or remove users from the team. They also have the power to remove a team
- Members: If you are a member of a team you receive the rights that are part of this team.
You can create and manage teams in the Settings page, visiting the Team tab. Once a team is created, you can assign projects and environments permissions to it, following the same roles as described above for users.
SSO Group Mapping
When using SSO teams can be integrated with the groups passed from your SSO integration.
To make use of this feature make sure your SAML identity provider sends an attribute statement named Groups.
Attributes such as http://schemas.microsoft.com/ws/2008/06/identity/claims/groups are not accepted.
This might mean you need to customize the Group claim for your identity provider.
When the Groups field is passed it can now be linked to a team. Fill in the group name that is passed from your SAML identity provider to Conveyor on a team.
This can be done in the UI of Conveyor on the teams page alternatively you can use the Conveyor terraform provider.
Once you have set the SSO Group mapping on a team, team membership is now managed via your SAML identity provider. You can not manually assign or remove members from the team anymore this is now automatically managed. Team membership is synced every time a user does a new login. We force users to do a login every day, but if you need a sync to happen faster you will have to tell the user to logout and login.
For more information on how to configure the integration for Microsoft Entra ID, you can follow our how-to guide.