Here you can manage who can access your Devtron instance and what actions they can perform. Use this section to add team members, assign them roles, and control their access by granting fine-grained permissions. Moreover, you can also download all user data in a CSV format.
This is a mandatory step after configuring SSO in Devtron; otherwise, your users won't be able to log in to Devtron via SSO.
Go to Global Configurations → Authorization → User Permissions.
Click Add Users.
In the Email addresses field, type the email address of the user you wish to add. You may add more than one email address.
(Optional) From the Assign user groups dropdown, you may assign one or more user groups to the user. This helps in identifying the group/team to which the user belongs (e.g., Security Team, Frontend Team, Department Leads) especially when adding larger teams.
There are two types of permissions in Devtron (click the links below to learn more):
Super admin permission for granting full access.
Specific permissions for granting cherry-picked access.
Click Save. You have successfully added your user(s).
Only existing super-admins can assign super-admin permissions to another user.
Before assigning this permission, please note the following:
Selecting this option will grant the user full access to all the resources.
Since super-admin permission is the highest level of access you can grant, we recommend you give it only to limited users.
You can revoke a user's super-admin access at any time and restrict it to specific permissions.
Only managers and super-admins can assign specific permissions to a user.
Upon selecting this option, you get two additional sections:
Section
Description
Permission Groups
Direct Permissions
This option allows you to grant your user the access to:
If you assign a permission group as well as direct permissions, the user will have the combined permissions of both.
For example:
A user is granted ‘Build & Deploy’ access to three apps via direct permissions.
The same user is part of a group that has ‘View only’ access to five apps (including those three apps).
Now, the user will have both ‘Build & Deploy’ and ‘View only’ permissions for those three apps, and just ‘View only’ for the other two.
The Devtron Apps tab is displayed only when the Build and Deploy (CI/CD) module is installed in your Devtron instance.
The Devtron Apps tab allows you to grant user permissions for Devtron applications.
Project
Select your preferred project from the drop-down box to grant the user access. You can select only one project at a time. Note: If you want to select more than one project, then click Add Permission.
Environment
Select a specific environment or all environments from the drop-down box as per your requirement.
Note: If you select All environments, the user will have access to all the current environments and any new environment which gets associated with the application in the future.
Application
Select a specific application or all applications from the drop-down box that is associated with the environment(s) selected in the Environment drop-down box, as per your requirement.
Note: If you select All applications, the user will have access to all the current and future applications associated with the project. Moreover, user with access to all applications, can create new applications too.
Role
Available Roles:
Base Role
Status
The role-based access for Devtron Apps are as follows:
Base Role
View only: Users can view applications and access environments but cannot view sensitive information like secrets used in applications or charts or perform any actions.
Build and Deploy: In addition to View only permission, users can build and deploy images of applications in permitted environments.
Admin: Users can create, edit, deploy, and delete permitted applications in permitted projects.
Manager: In addition to Admin permission, users can also grant or revoke user access for applications and environments that they manage.
Additional Roles is an enterprise feature that allows you to assign specific permissions to a user beyond their Base Role. For example, you can grant a user both the Build and Deploy (Base Role) and Config Approver permissions (Additional Role). This allows the user to build and deploy images, while also being responsible for approving configuration change requests.
The following permissions are currently available in Additional Roles:
Config Approver: You can approve configuration change requests for Deployment Templates, ConfigMaps, and Secrets. However, you cannot self-approve your own proposed changes, even if you have the Config Approver permission or even the Super Admin access.
Artifact promoter: You can approve the promotion of artifacts directly to the target CD pipeline. For example, if your application workflow includes three CD pipelines (e.g., dev, qa, and prod) and someone raises a request to bypass dev and qa and deploy the artifact directly to prod, you can approve and perform this action with the Artifact promoter permission.
Deployment approver: You can approve the image deployment requests.
Access Manager is an enterprise feature that allows you to manage user permissions on a granular level. As an Access Manager, you can assign or revoke permissions of existing users within your granted scope.
For example, when a Super-Admin creates an Access Manager and grants him View only access under Base Role, and Admin, Config Approver permissions under the Access Manager role, then the Access Manager will have View only access across Devtron and will not be able to perform any other operations.
However, he will still be able to assign View only access, assign or revoke Admin and Config Approver permissions to other existing users. This is possible because the Super-Admin has explicitly granted those permissions under the Access Manager role when creating the Access Manager.
An Access Manager cannot create other Access Managers or add new users. Creation of new users and Access Manager is restricted only to Super-Admins.
If a Super-Admin enables the Can manage access for all roles toggle for a user, then that user can modify permissions of existing users and even Super-Admin. However, he will still not be able to create a Super-Admin or new users. The Can manage access for all roles toggle is exclusively available to Super-Admin and is not visible to any other users.
Enabling this toggle, however, does not grant the user the ability to give another user the Access Manager role. For example, when a Super-Admin enables the Can manage access for all roles toggle for a user, then for that user, the Access Manager toggle will not be available in the Role drop-down box, thereby restricting the ability to create Access Managers to Super-Admin.
The Access Manager toggle in the Role drop-down box is disabled by default.
When a Super-Admin creates a new user or edits the permissions of an existing user, if he enables the Access Manager toggle from the Role drop-down box but do not select any permissions, the system treats it as if the toggle were never enabled. In other words, enabling the toggle without assigning any permissions has no effect. Therefore, when enabling the Access Manager toggle, it is recommended to select at least one permission to ensure the role is active.
The following permissions are currently available in the Access Manager role:
View only: When selected, this permission allows you to grant or revoke View Only access to other users.
Build and Deploy: When selected, this permission allows you to grant or revoke Build and Deploy access to other users.
Admin: When selected, this permission allows you to grant or revoke Admin access to other users.
Config Approver: When selected, this permission allows you to grant or revoke Config Approver access to other users.
Artifact promoter: When selected, this permission allows you to grant or revoke Artifact promoter access to other users.
The Deployment approver permission is not currently available within the Access Manager role. If you would like to see this permission included, we encourage you to raise a feature request on GitHub.
An Access Manager cannot modify Super-Admin permissions. If an Access Manager attempts to perform any action beyond their granted scope, the system will display an appropriate error message. For example, when modifying the permissions of an existing user, if the Access Manager only has the View only permission, but attempt to assign Build and Deploy permission to the existing user, an error message is displayed.
Similarly, if an Access Manager has View Only access, but attempts to modify an existing user who currently has Admin access, the Access Manager can downgrade the user’s access to View only. But, he will not be able to reassign Admin access afterward, as he himself do not hold that permission and an appropriate error message is displayed. Access Managers can only modify permissions that fall within their own granted scope.
When an Access Manager modifies and assigns the Artifact Promoter permission to an existing user, for example, then that user will only have Artifact Promoter permission selected and displayed in the Role drop-down box, whereas the other permissions, Config Approver and Deployment approver, will not be displayed.
However, Super-Admin users have unrestricted access to all Devtron resources. They can create, modify, delete, and manage any resource, including user access, Git repositories, container registries, clusters, and environments.
View
✅
❌
❌
❌
❌
❌
❌
❌
❌
Build and Deploy
✅
❌
❌
❌
✅
❌
❌
❌
❌
Admin
✅
✅
✅
✅
✅
❌
❌
❌
❌
Manager
✅
✅
✅
✅
✅
❌
❌
❌
✅
Deployment Approver
✅
❌
❌
❌
❌
✅
❌
❌
❌
Configuration Approver
✅
❌
❌
❌
❌
❌
✅
❌
❌
Artifact Promoter
✅
❌
❌
❌
❌
❌
❌
✅
❌
Super Admin
✅
✅
✅
✅
✅
✅
✅
✅
✅
Here you can grant your user the permissions for Helm apps deployed from Devtron or outside Devtron.
Project
Select a project from the dropdown list to grant the user access. You can select only one project at a time. Note: If you want to select more than one project, then click Add Permission.
Environment or Cluster/Namespace
Select a specific environment from the dropdown list.
Note: If you select All existing + future environments in cluster, then the user will get access to all the current environments including any new environment which gets associated with the application later.
Application
Select a specific helm application or all helm apps from the dropdown list corresponding to your selected environments.
Note: If All applications is selected, the user will have access to all current and future applications associated with the project.
Permission
Available Permissions:
View only
View & Edit
Admin
Status
There are three role-based access levels for Helm Apps:
View only: Users with this role can only view Helm applications and their configurations but cannot make any modifications.
View & Edit: These users can modify the configurations of permitted Helm applications and deploy them.
Admin: Users with this role have full access to Helm applications, including the ability to create, manage, and delete applications.
View only
✅
❌
❌
❌
❌
View & Edit
✅
❌
✅
✅
❌
Admin
✅
✅
✅
✅
✅
Super Admin
✅
✅
✅
✅
✅
Here you can grant your user the permissions to access the jobs created in Devtron.
Project
Select a project from the dropdown list to grant the user access. You can select only one project at a time. Note: If you want to select more than one project, then click Add Permission.
Job Name
Select a specific job or choose All jobs to grant access to all available jobs within the project.
Workflow
Select a specific workflow or All workflows to grant access to the workflows containing the job pipelines.
Environment
Select a specific environment or All environments to grant access to the environments associated with the job(s).
Role
Available Roles:
View only
Run job
Admin
Status
There are three role-based access levels for Jobs:
View only: Users can view the job workflows and logs but cannot trigger or modify jobs.
Run Job: These users can trigger jobs but cannot make modifications to workflows.
Admin: Users with this role have full control over jobs, including creating, modifying, and deleting workflows.
View only
✅
❌
❌
❌
❌
Run job
✅
❌
✅
❌
❌
Admin
✅
✅
✅
✅
✅
Super Admin
✅
✅
✅
✅
✅
Here you can provide permission to view, inspect, manage, and delete resources in your clusters from Devtron's Resource Browser.
To grant Kubernetes resource permission, click Add permission.
Cluster
Select a cluster from the dropdown list to which you want to give permission to the user. You can select only one cluster at a time. Note: To add another cluster, click Add another.
Namespace
Select a namespace from the dropdown list.
API Group
Select a specific API group or All API groups from the dropdown list corresponding to the Kubernetes resource.
Kind
Select a kind or All kind from the dropdown list corresponding to the Kubernetes resource.
Resource name
Select a resource name or All resources from the dropdown list to which you want to give permission to the user.
Role
Available Roles:
View
Admin
Status
There are two role-based access levels for Kubernetes Resources:
View: Users with this role can inspect Kubernetes resources but cannot make changes.
Admin: Users can create, modify, and delete Kubernetes resources within their assigned namespaces and clusters.
View
✅
❌
❌
❌
Admin
✅
✅
✅
✅
Super Admin
✅
✅
✅
✅
Here you can grant your user the permissions for accessing Chart Groups. Note that you can only give users the permission to either create chart groups or edit them, but not both.
View
Click the View checkbox if you want the user(s) to view only the chart groups.
Create
Click the Create checkbox if you want the user(s) to create, view, or delete the chart groups.
Edit
Deny: Select Deny from the dropdown list to restrict the users from editing the chart groups.
Specific Chart Groups: Select the Specific Charts Groups option from the dropdown list and then select the chart group for which you want to allow users to edit.
View: Users can view chart groups but cannot create or edit them.
Create: Users can create new chart groups and modify existing ones.
Edit: Users can modify chart groups but cannot create new ones.
View
✅
❌
❌
❌
❌
Create
✅
✅
❌
✅
✅
Edit
✅
❌
❌
None/Specific Groups
❌
Super Admin
✅
✅
✅
✅
✅
Super-admins can activate or deactivate users.
Managers can activate or deactivate users only if the users has the same or fewer permissions than the manager.
When working with multiple collaborators in Devtron, you may need to deactivate users who no longer require access and reactivate them when needed. This applies to users of Devtron Apps, Helm Apps, Jobs, and Kubernetes Resources.
You can manage a user's active status at three levels:
User-level
Permission Group-level
Direct Permissions-level
Active/Activate - Use this option to activate a deactivated user while retaining their previous roles and permissions.
Inactive/Inactivate - Use this option to deactivate an existing active user and save the changes. If the user has an ongoing session, they will be logged out permanently on their next action or refresh.
Keep active until - Use this TTL-based option to keep a user active only till a specified date and time, after which the user is automatically deactivated. The user will not be able to log in to Devtron.
Active/Activate - Use this option to allow permissions from the group to take effect for the user.
Inactive/Inactivate - Use this option to prevent permissions from the group from taking effect for the user. However, they can still log in/log out of Devtron if active at the user-level.
Keep active until - Use this TTL-based option to grant group permissions to the user until a set date, after which permission group will become inactive for the user.
Active/Activate - Use this option to grant the project/resource access to the user.
Inactive/Inactivate - Use this option to revoke the project/resource access from the user. Note: The user will still be able to log in/log out of Devtron if active at user-level.
Keep active until - Use this TTL-based option to grant the project/resource access to the user only till a specified date and time, beyond which the user will no longer have access to the project/resource.
Super-admins can edit user permissions.
Managers can edit user permissions only if the user has the same or fewer permissions than the manager.
Direct user permissions cannot be edited if you're using LDAP/Microsoft for SSO with 'auto-assign permission' enabled. Permissions can only be managed via permission groups in such a scenario.
You can edit the user permissions by clicking the edit icon. Click Save after editing the permissions.
You may download the user data of current users and deleted users in a CSV format. Broadly, your exported CSV will include:
User's Email address
User ID & Status (Active/Inactive/Deleted)
Last Login Time
Detailed Permissions
Role
Timestamps for User Addition, Updation, and Deletion
Super-admins can delete users.
Managers can delete users only if the user has the same or fewer permissions than the manager.
If you want to delete a user, click Delete.
This will remove the user from the system along with all the permissions granted earlier. The user will no longer be able to log in to Devtron unless added again.
(Recommended, ) Use the dropdown to assign the user to a permission group. Your user will automatically inherit all the permissions to the projects/resources defined for that group. You may select more than one permission group too. Once you select a permission group, assigning direct permissions can be skipped (unless you wish to grant additional permissions). You may also at permission group-level. We recommend using permission groups over direct permissions for easier management of user access.
Additional Roles
Access Manager
to learn more about the role you wish to assign to the user.
Read:
Additional Roles
Access Manager
to learn more about the permission you wish to assign the user.
Read:
to learn more about the role you wish to assign the user.
Read:
to learn more about the role you wish to assign the user.
Read:
