Try Devtron Enterprise!
Start Free Trial
LogoLogo
WebsiteDevtron demoGithub RepoJoin Discord
v0.7
v0.7
  • Introduction
  • Getting Started
  • Install Devtron
    • Install Devtron with CI/CD
    • Install Devtron with CI/CD and GitOps (Argo CD)
    • Install Devtron without Integrations
    • Install Devtron on Minikube, Microk8s, K3s, Kind, Cloud VMs
    • Install Devtron on Airgapped Environment
    • Demo on Popular Cloud Providers
    • Backup for Disaster Recovery
    • Uninstall Devtron
    • FAQs
  • Install Devtron Enterprise Trial
  • Devtron Kubernetes Client
  • Configurations
    • Installation Configurations
    • Override Configurations
    • Ingress Setup
  • Global Configurations
    • Host URL
    • GitOps
    • Projects
    • Clusters & Environments
    • Git Accounts
    • Container/OCI Registry
    • Chart Repositories
    • Deployment Charts
    • Authorization
      • SSO Login Services
        • Google
        • GitHub
        • GitLab
        • Microsoft
        • LDAP
        • OIDC
          • Keycloak
          • Okta
        • OpenShift
      • User Permissions
      • Permission Groups
      • API Tokens
    • Notifications
    • Deployment Window
    • Approval Policy
    • External Links
    • Catalog Framework
    • Scoped Variables
    • Plugin Policy
    • Pull Image Digest
    • Tags Policy
    • Filter Condition
    • Lock Deployment Configuration
    • Image Promotion Policy
    • Build Infra
  • Devtron Upgrade
    • Update Devtron from Devtron UI
    • Upgrade to 1.5.0
    • 0.6.x-0.7.x
    • 0.5.x-0.6.x
    • 0.4.x-0.5.x
    • 0.4.x-0.4.x
    • 0.3.x-0.4.x
    • 0.3.x-0.3.x
    • 0.2.x-0.3.x
  • Usage
    • Applications
      • Create a New Application
      • Clone an Existing Application
      • Deploy a Sample Application
      • App Configuration
        • Git Repository
        • Build Configuration
        • Base Deployment Template
          • Deployment
          • Rollout Deployment
          • Job and Cronjob
          • StatefulSets
        • GitOps Configuration
        • Workflow Editor
          • CI Pipeline
            • Pre-Build/Post-Build Stages
            • Override Build Configuration
          • CD Pipeline
        • ConfigMaps
        • Secrets
          • External Secret Operator (ESO)
            • AWS Secrets Manager
            • Google Secrets Manager
            • HashiCorp Vault
        • Environment Overrides
        • Deleting Application
      • Build and Deploy
        • Triggering CI
        • Triggering CD
        • Rollback Deployment
        • Applying Labels to Images
      • App Details
        • Debugging Deployment And Monitoring
        • Using Ephemeral Containers
        • Application Metrics
      • Application Overview
    • Jobs
      • Create a new job
      • Configurations
      • Workflow Editor
      • Trigger Job
      • Overview
    • Application Groups
    • Software Distribution Hub
      • Tenants
      • Release Hub
    • Resource Browser
    • Resource Watcher
    • Charts
      • Charts Overview
      • Deploy & Observe
      • Examples
        • Deploying Mysql Helm Chart
        • Deploying MongoDB Helm Chart
      • Chart Group
    • Security
      • Security Scans
      • Security Policies
    • Bulk Edit
    • Integrations
      • Build and Deploy (CI/CD)
      • GitOps (Argo CD)
      • Vulnerability Scanning (Clair)
      • Notifications
      • Monitoring (Grafana)
    • Pipeline Plugins
      • Create Your Plugin
      • Our Plugins
        • Ansible Runner
        • Bitbucket Runner Trigger
        • Codacy
        • Code-Scan
        • Copacetic
        • Container Image Exporter
        • Copy Container Image
        • Cosign
        • CraneCopy
        • Dependency track - Maven & Gradle
        • Dependency track - NodeJS
        • Dependency track - Python
        • Devtron CD Trigger
        • Devtron CI Trigger
        • Devtron Job Trigger
        • DockerSlim
        • EKS Create Cluster
        • GCS Create Bucket
        • GitHub Pull Request Updater
        • GKE Provisioner
        • GoLang-migrate
        • Jenkins
        • Jira Issue Validator
        • Jira Issue Updater
        • K6 Load Testing
        • Pull images from container repository
        • Semgrep
        • SonarQube
        • SonarQube v1.1.0
        • Terraform CLI
        • Vulnerability Scanning
  • Resources
    • Glossary
    • Troubleshooting
    • Use Cases
      • Devtron Generic Helm Chart To Run CronJob Or One Time Job
      • Connect SpringBoot with Mysql Database
      • Connect Expressjs With Mongodb Database
      • Connect Django With Mysql Database
      • Pull Helm Charts from OCI Registry
    • Telemetry Overview
    • Devtron on Graviton
    • Release Notes
Powered by GitBook
On this page
  • Introduction
  • Add Users
  • Grant Super Admin Permission
  • Grant Specific Permissions
  • Devtron Apps permissions
  • Helm Apps permissions
  • Jobs permissions
  • Kubernetes Resources permissions
  • Chart Groups permissions
  • Making Users Active/Inactive
  • At User level
  • At Permission Group level
  • At Direct Permissions level
  • Edit User Permissions
  • Export User Data to CSV
  • Delete Users

Was this helpful?

Export as PDF
  1. Global Configurations
  2. Authorization

User Permissions

PreviousOpenShiftNextPermission Groups

Last updated 1 month ago

Was this helpful?

Introduction

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.

Figure 1: User Permissions - Example

Add Users

Mandatory Action

This is a mandatory step after configuring SSO in Devtron; otherwise, your users won't be able to log in to Devtron via SSO.

Who Can Perform This Action?

Only managers and super-admins can add users.

  1. Go to Global Configurations → Authorization → User Permissions.

  2. Click Add Users.

  3. In the Email addresses field, type the email address of the user you wish to add. You may add more than one email address.

  4. (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.

  5. There are two types of permissions in Devtron (click the links below to learn more):

  6. Click Save. You have successfully added your user(s).


Grant Super Admin Permission

Who Can Perform This Action?

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.


Grant Specific Permissions

Who Can Perform This Action?

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:

What happens when a user has direct permissions as well as permissions inherited from a group?

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.

Devtron Apps permissions

Note

Here you can grant your user the permissions for Devtron apps.

Field
Description

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

Select a specific environment or all environments from the dropdown list. Note: If you select All environments, the user will have access to all the current environments including any new environment which gets associated with the application later.

Application

Select a specific application or all applications from the dropdown list corresponding to your selected environments. Note: If you select All applications, the user will have access to all current and future applications associated with the project. Moreover, user with access to all applications, can create new applications too.

Role

Available Roles:

  • View only

  • Build and Deploy

  • Admin

  • Manager

Status

Roles available for Devtron Apps

There are seven role-based access levels for Devtron Apps:

  1. View only: These users can view applications and environments access to but cannot view sensitive data like secrets used in applications or charts.

  2. Build and Deploy: In addition to View only access, these users can build and deploy images of applications to permitted environments.

  3. Admin: These users can create, edit, deploy, and delete permitted applications in selected projects.

  4. Manager: These users have the same permissions as Admin but can also grant or revoke user access for applications and environments they manage.

  5. Image approver: These users can approve image deployment requests.

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.

Role
View
Create
Edit
Delete
Build & Deploy
Approve Images
Approve Config Change
Approve Artifacts
Manage User Access

View

✅

❌

❌

❌

❌

❌

❌

❌

❌

Build and Deploy

✅

❌

❌

❌

✅

❌

❌

❌

❌

Admin

✅

✅

✅

✅

✅

❌

❌

❌

❌

Manager

✅

✅

✅

✅

✅

❌

❌

❌

✅

Image Approver

✅

❌

❌

❌

❌

✅

❌

❌

❌

Configuration Approver

✅

❌

❌

❌

❌

❌

✅

❌

❌

Artifact Promoter

✅

❌

❌

❌

❌

❌

❌

✅

❌

Super Admin

✅

✅

✅

✅

✅

✅

✅

✅

✅

Helm Apps permissions

Here you can grant your user the permissions for Helm apps deployed from Devtron or outside Devtron.

Field
Description

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

Roles available for Helm Apps

There are three role-based access levels for Helm Apps:

  1. View only: Users with this role can only view Helm applications and their configurations but cannot make any modifications.

  2. View & Edit: These users can modify the configurations of permitted Helm applications and deploy them.

  3. Admin: Users with this role have full access to Helm applications, including the ability to create, manage, and delete applications.

Role
View
Create
Deploy
Edit
Delete

View only

✅

❌

❌

❌

❌

View & Edit

✅

❌

✅

✅

❌

Admin

✅

✅

✅

✅

✅

Super Admin

✅

✅

✅

✅

✅

Jobs permissions

Here you can grant your user the permissions to access the jobs created in Devtron.

Field
Description

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

Roles available for Jobs

There are three role-based access levels for Jobs:

  1. View only: Users can view the job workflows and logs but cannot trigger or modify jobs.

  2. Run Job: These users can trigger jobs but cannot make modifications to workflows.

  3. Admin: Users with this role have full control over jobs, including creating, modifying, and deleting workflows.

Role
View
Create
Run
Edit
Delete

View only

✅

❌

❌

❌

❌

Run job

✅

❌

✅

❌

❌

Admin

✅

✅

✅

✅

✅

Super Admin

✅

✅

✅

✅

✅

Kubernetes Resources permissions

Note

The 'Kubernetes Resources' tab will be available only if you have super-admin permissions.

To grant Kubernetes resource permission, click Add permission.

Field
Description

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

Roles available for Kubernetes Resources

There are two role-based access levels for Kubernetes Resources:

  1. View: Users with this role can inspect Kubernetes resources but cannot make changes.

  2. Admin: Users can create, modify, and delete Kubernetes resources within their assigned namespaces and clusters.

Role
View
Create
Edit
Delete

View

✅

❌

❌

❌

Admin

✅

✅

✅

✅

Super Admin

✅

✅

✅

✅

Chart Groups permissions

Note

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.

Action
Permissions

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.

Roles available for Chart Groups

  1. View: Users can view chart groups but cannot create or edit them.

  2. Create: Users can create new chart groups and modify existing ones.

  3. Edit: Users can modify chart groups but cannot create new ones.

Role
View
Create
Deploy
Edit
Delete

View

✅

❌

❌

❌

❌

Create

✅

✅

❌

✅

✅

Edit

✅

❌

❌

None/Specific Groups

❌

Super Admin

✅

✅

✅

✅

✅


Who Can Perform This Action?

  • 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:

At User 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.

At Permission Group level

  • Active/Activate - Use this option to allow permissions from the group to take effect for the user.

  • 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.

At Direct Permissions level

  • Active/Activate - Use this option to grant the project/resource access to the user.

  • 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.


Edit User Permissions

Who Can Perform This Action?

  • Super-admins can edit user permissions.

  • Managers can edit user permissions only if the user has the same or fewer permissions than the manager.

Note

You can edit the user permissions by clicking the edit icon. Click Save after editing the permissions.


Export User Data to CSV

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


Delete Users

Who Can Perform This Action?

  • 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.

Figure 2: User Permissions in Global Configurations
Figure 3: 'Add Users' Button
Figure 4: Adding Email Addresses of Users
Figure 5: Assigning User Group(s)

for granting full access.

for granting cherry-picked access.

Figure 6: Granting Specific or Superadmin Access
Figure 7: Granting Superadmin Access

You can revoke a user's super-admin access at any time and restrict it to .

Figure 8: Granting Specific Access

(Recommended, ) Use the dropdown to assign the user to a . 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.

The 'Devtron Apps' tab will be available only if the is installed.

Figure 9: Granting Devtron Apps Permissions

to learn more about the role you wish to assign the user.

Read:

Configuration approver: These users can approve configuration change requests for , , and . However, users cannot self-approve their own proposed changes, even if they have this role or Super Admin access.

Artifact promoter: These users have the authority to approve the promotion of directly to the target CD pipeline.

Figure 10: Granting Helm Apps Permissions

to learn more about the permission you wish to assign the user.

Read:

Figure 11: Granting Jobs Permissions

to learn more about the role you wish to assign the user.

Read:

Here you can provide permission to view, inspect, manage, and delete resources in your clusters from .

Figure 12a: Adding Permissions for Kubernetes Resources
Figure 12b: Granting Permissions for Kubernetes Resources

to learn more about the role you wish to assign the user.

Read:

The 'Chart Groups' tab will be available only if the is installed.

Figure 13: Granting Chart Group Permissions

Making Users Active/Inactive

Figure 14: Active/Inactive Options

Figure 15: Active/Inactive User
Figure 16: Active/Inactive User from Permission Group

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 .

Figure 17: Active/Inactive User for Project Access

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 .

Direct user permissions cannot be edited if you're using / for SSO with 'auto-assign permission' enabled. Permissions can only be in such a scenario.

Figure 18: Editing User Permissions
Figure 19: Exporting User Data
Figure 20: Deleting a User
CI/CD module
Deployment Templates
ConfigMaps
Secrets
Devtron's Resource Browser
CI/CD module
Super admin permission
Specific permissions
specific permissions
User-level
Permission Group-level
Direct Permissions-level
active at the user-level
active at user-level
see snapshot
permission group
make users Active/Inactive
Devtron Apps
Helm Apps
Jobs
Kubernetes Resources
Chart Groups
Click here
Click here
Click here
Click here
artifacts
LDAP
Microsoft
Making Users Active/Inactive
Making Users Active/Inactive
Making Users Active/Inactive
Making Users Active/Inactive
managed via permission groups