Permissions and roles

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

When you add a user to a project or group, you assign them a role. The role determines which actions they can take in GitLab.

If you add a user to both a project’s group and the project itself, the higher role is used.

GitLab administrators have all permissions.

Roles

You can assign users a default role or a custom role.

The available default roles are:

  • Guest (This role applies to private and internal projects only.)
  • Reporter
  • Developer
  • Maintainer
  • Owner
  • Minimal Access (available for the top-level group only)

A user assigned the Guest role has the least permissions, and the Owner has the most.

By default, all users can create top-level groups and change their usernames. A GitLab administrator can change this behavior for the GitLab instance.

Project members permissions

A user’s role determines what permissions they have on a project. The Owner role provides all permissions but is available only:

  • For group and project Owners.
  • For Administrators.

Personal namespace owners:

  • Are displayed as having the Maintainer role on projects in the namespace, but have the same permissions as a user with the Owner role.
  • For new projects in the namespace, are displayed as having the Owner role.

For more information about how to manage project members, see members of a project.

The following table lists project permissions available for each role:

Action Guest Reporter Developer Maintainer Owner Notes
Analytics:
View issue analytics
 
Analytics:
View value stream analytics
 
Analytics:
View DORA metrics
   
Analytics:
View CI/CD analytics
   
Analytics:
View code review analytics
   
Analytics:
View merge request analytics
   
Analytics:
View repository analytics
   
Application security:
View licenses in dependency list
     
Application security:
Create and run on-demand DAST scans
     
Application security:
View dependency list
     
Application security:
Create a CVE ID Request
       
Application security:
Create or assign security policy project
         
Application security:
Create, edit, delete individual security policies
     
Container Registry:
Create, edit, delete cleanup policies
       
Container registry:
Push an image to the container registry
     
Container registry:
Pull an image from the container registry
The ability to view the container registry and pull images is controlled by the container registry’s visibility permissions.
Container registry:
Remove a container registry image
     
GitLab agent for Kubernetes:
View agents
     
GitLab agent for Kubernetes:
Manage agents
       
GitLab Pages:
View Pages protected by access control
 
GitLab Pages:
Manage
       
GitLab Pages:
Manage GitLab Pages domains and certificates
       
GitLab Pages:
Remove GitLab Pages
       
Incident Management:
Assign an alert
 
Incident Management:
Participate in on-call rotation
 
Incident Management:
View incident
 
Incident Management:
Change alert status
   
Incident Management:
Change incident severity
   
Incident Management:
Create incident
   
Incident Management:
View alerts
   
Incident Management:
View escalation policies
   
Incident Management:
View on-call schedules
   
Incident Management:
Change incident escalation status
     
Incident Management:
Change incident escalation policy
     
Incident Management:
Manage on-call schedules
       
Incident Management:
Manage escalation policies
       
Issue boards:
Create or delete lists
   
Issue boards:
Move issues between lists
   
Issues:
Add Labels
Guest users can only set metadata (for example, labels, assignees, or milestones) when creating an issue. They cannot change the metadata on existing issues.
Issues:
Add to epic
  You must have permission to view the epic.
Issues:
Assign
Guest users can only set metadata (for example, labels, assignees, or milestones) when creating an issue. They cannot change the metadata on existing issues.
Issues:
Create
Authors and assignees can modify the title and description even if they don’t have the Reporter role.
Issues:
Create confidential issues
 
Issues:
View Design Management pages
 
Issues:
View related issues
 
Issues:
Set weight
   
Issues:
Set metadata such as labels, milestones, or assignees when creating an issue
Guest users can only set metadata (for example, labels, assignees, or milestones) when creating an issue. They cannot change the metadata on existing issues.
Issues:
Edit metadata such labels, milestones, or assignees for an existing issue
  Guest users can only set metadata (for example, labels, assignees, or milestones) when creating an issue. They cannot change the metadata on existing issues.
Issues:
Set parent epic
   
Issues:
View confidential issues
  Guest users can only view the confidential issues they created themselves or are assigned to.
Issues:
Close / reopen
  Authors and assignees can close and reopen issues even if they don’t have the Reporter role.
Issues:
Lock threads
   
Issues:
Manage related issues
 
Issues:
Manage tracker
   
Issues:
Move issues
  Attached design files are moved together with the issue.
Issues:
Set issue time tracking estimate and time spent
   
Issues:
Archive Design Management files
   
Issues:
Upload Design Management files
   
Issues:
Delete
         
License Scanning:
View allowed and denied licenses
On self-managed GitLab instances, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must be given explicit access (at least the Reporter role) even if the project is internal. Users with the Guest role on GitLab.com are only able to perform this action on public projects because internal visibility is not available.
License Scanning:
View License Compliance reports
On self-managed GitLab instances, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must be given explicit access (at least the Reporter role) even if the project is internal. Users with the Guest role on GitLab.com are only able to perform this action on public projects because internal visibility is not available.
License Scanning:
View License list
   
License approval policies:
Manage license policy
       
Merge requests:
View a merge request
On self-managed GitLab instances, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must be given explicit access (at least the Reporter role) even if the project is internal. Users with the Guest role on GitLab.com are only able to perform this action on public projects because internal visibility is not available.
Merge requests:
Assign reviewer
     
Merge requests:
View list
  Members with the Guest role can view the list of MRs in public projects. Private projects restrict Guests from viewing MR lists.
Merge requests:
Apply code change suggestions
     
Merge requests:
Approve
    For information on eligible approvers for merge requests, see Eligible approvers.
Merge requests:
Assign
     
Merge requests:
Create
    In projects that accept contributions from external members, users can create, edit, and close their own merge requests.
Merge requests:
Add labels
     
Merge requests:
Lock threads
     
Merge requests:
Manage or accept
     
Merge requests:
Resolve a thread
     
Merge requests:
Manage merge approval rules (project settings)
       
Merge requests:
Delete
         
Objectives and key results:
Add a child OKR
 
Objectives and key results:
Add a linked item
 
Objectives and key results:
Create
 
Objectives and key results:
View
 
Objectives and key results:
Change confidentiality
   
Objectives and key results:
Edit
   
Package registry:
Pull a package
On self-managed GitLab instances, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must be given explicit access (at least the Reporter role) even if the project is internal. Users with the Guest role on GitLab.com are only able to perform this action on public projects because internal visibility is not available.
Package registry:
Publish a package
     
Package registry:
Delete a package
       
Package registry:
Delete a file associated with a package
       
Project operations:
View Error Tracking list
   
Project operations:
Manage Feature flags
     
Project operations:
Manage Error Tracking
       
Projects:
Download project
On self-managed GitLab instances, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must be given explicit access (at least the Reporter role) even if the project is internal. Users with the Guest role on GitLab.com are only able to perform this action on public projects because internal visibility is not available.
Projects:
Leave comments
 
Projects:
Reposition comments on images (posted by any user)
Applies only to comments on Design Management designs.
Projects:
View Insights
 
Projects:
View releases
Guest users can access GitLab Releases for downloading assets but are not allowed to download the source code nor see repository information like commits and release evidence.
Projects:
View Requirements
 
Projects:
View time tracking reports
On self-managed GitLab instances, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must be given explicit access (at least the Reporter role) even if the project is internal. Users with the Guest role on GitLab.com are only able to perform this action on public projects because internal visibility is not available.
Projects:
View wiki pages
 
Projects:
Create snippets
   
Projects:
Manage labels
   
Projects:
View project traffic statistics
   
Projects:
Create, edit, delete milestones.
   
Projects:
Create, edit, delete releases
    If the tag is protected, this depends on the access given to Developers and Maintainers.
Projects:
Create, edit wiki pages
     
Projects:
Enable review apps
     
Projects:
View project Audit Events
    Users can only view events based on their individual actions.
Projects:
Add deploy keys
       
Projects:
Add new team members
       
Projects:
Manage team members
      Maintainers cannot create, demote, or remove Owners, and they cannot promote users to the Owner role. They also cannot approve Owner role access requests.
Projects:
Change project features visibility level
      A Maintainer or Owner can’t change project features visibility level if project visibility is set to private.
Projects:
Configure webhooks
       
Projects:
Delete wiki pages
     
Projects:
Edit comments (posted by any user)
       
Projects:
Edit project badges
       
Projects:
Edit project settings
       
Projects:
Export project
       
Projects:
Manage project access tokens
      For self-managed GitLab, project access tokens are available in all tiers. For GitLab.com, project access tokens are supported in the Premium and Ultimate tier (excluding trial licenses).
Projects:
Manage Project Operations
       
Projects:
Rename project
       
Projects:
Share (invite) projects with groups
      When Share Group Lock is enabled the project can’t be shared with other groups. It does not affect group with group sharing.
Projects:
View 2FA status of members
       
Projects:
Assign project to a compliance framework
         
Projects:
Archive project
         
Projects:
Change project visibility level
         
Projects:
Delete project
         
Projects:
Disable notification emails
         
Projects:
Transfer project to another namespace
         
Projects: View Usage Quotas page        
Repository:
Pull project code
On self-managed GitLab instances, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must be given explicit access (at least the Reporter role) even if the project is internal. Users with the Guest role on GitLab.com are only able to perform this action on public projects because internal visibility is not available.
Repository:
View project code
On self-managed GitLab instances, users with the Guest role are able to perform this action only on public and internal projects (not on private projects). External users must be given explicit access (at least the Reporter role) even if the project is internal. Users with the Guest role on GitLab.com are only able to perform this action on public projects because internal visibility is not available. In GitLab 15.9 and later, users with the Guest role and an Ultimate license can view private repository content if an administrator (on self-managed or GitLab Dedicated) or group owner (on GitLab.com) gives those users permission. The administrator or group owner can create a custom role through the API or UI and assign that role to the users.
Repository:
View a commit status
   
Repository:
Add tags
     
Repository:
Create new branches
     
Repository:
Create or update commit status
    If the branch is protected, this depends on the access given to Developers and Maintainers.
Repository:
Force push to non-protected branches
     
Repository:
Push to non-protected branches
     
Repository:
Remove non-protected branches
     
Repository:
Rewrite or remove Git tags
     
Repository:
Enable or disable branch protection
       
Repository:
Enable or disable tag protection
       
Repository:
Manage push rules
       
Repository:
Push to protected branches
      If the branch is protected, this depends on the access given to Developers and Maintainers.
Repository:
Turn on or off protected branch push for developers
       
Repository:
Remove fork relationship
         
Repository:
Force push to protected branches
          Not allowed for Guest, Reporter, Developer, Maintainer, or Owner. See protected branches.
Repository:
Remove protected branches by using the UI or API
       
Requirements Management:
Archive / reopen
  Authors and assignees can archive and re-open even if they don’t have the Reporter role.
Requirements Management:
Create / edit
  Authors and assignees can modify the title and description even if they don’t have the Reporter role.
Requirements Management:
Import / export
   
Security dashboard:
Create issue from vulnerability finding
     
Security dashboard:
Create vulnerability from vulnerability finding
     
Security dashboard:
Use security dashboard
     
Security dashboard:
View vulnerability
     
Security dashboard:
View vulnerability findings in dependency list
     
Tasks:
Add a linked item
 
Tasks:
Create
  Authors and assignees can modify the title and description even if they don’t have the Reporter role.
Tasks:
Edit
   
Tasks:
Remove from issue
   
Tasks:
Delete
        Authors of tasks can delete them even if they don’t have the Owner role, but they have to have at least the Guest role for the project.
Terraform:
Read Terraform state
     
Terraform:
Manage Terraform state
       
Test cases:
Archive
   
Test cases:
Create
   
Test cases:
Move
   
Test cases:
Reopen
   
Vulnerability:
Change vulnerability status
      The admin_vulnerability permission was removed from the Developer role in GitLab 17.0.

GitLab CI/CD permissions

GitLab CI/CD permissions for some roles can be modified by these settings:

  • Public pipelines: When set to public, gives access to certain CI/CD features to Guest project members.
  • Pipeline visibility: When set to Everyone with Access, gives access to certain CI/CD “view” features to non-project members.
Action Non-member Guest Reporter Developer Maintainer Owner Notes
See that artifacts exist Non-members and guests: Only if the project is public.
View a list of jobs Non-members: Only if the project is public and Public pipelines is enabled in Project Settings > CI/CD.
Guests: Only if Public pipelines is enabled in Project Settings > CI/CD.
View and download artifacts Non-members: Only if the project is public, Public pipelines is enabled in Project Settings > CI/CD, and artifacts:public: false is not set on the job.
Guests: Only if Public pipelines is enabled in Project Settings > CI/CD and artifacts:public: false is not set on the job.
Reporters: Only if artifacts:public: false is not set on the job.
View environments Non-members and guests: Only if the project is public.
View job logs and job details page Non-members: Only if the project is public and Public pipelines is enabled in Project Settings > CI/CD.
Guests: Only if Public pipelines is enabled in Project Settings > CI/CD.
View pipelines and pipeline details pages Non-members: Only if the project is public and Public pipelines is enabled in Project Settings > CI/CD.
Guests: Only if Public pipelines is enabled in Project Settings > CI/CD.
View pipelines tab in MR Non-members and guests: Only if the project is public.
View vulnerabilities in a pipeline   Guests: Only if Public pipelines is enabled in Project Settings > CI/CD.
Run deployment job for a protected environment     Reporters: Only if the user is part of a group with access to the protected environment.
Developers and maintainers: Only if the user is allowed to deploy to the protected branch.
View and download project-level Secure Files        
Retry jobs        
Cancel jobs       Cancellation permissions can be restricted in the pipeline settings.
Create new environments        
Delete job logs or job artifacts       Developers: Only if the job was triggered by the user and runs for a non-protected branch.
Run CI/CD pipeline        
Run CI/CD pipeline for a protected branch       Developers and maintainers: Only if the user is allowed to merge or push to the protected branch.
Stop environments        
View a job with debug logging        
Use pipeline editor        
Run interactive web terminals        
Add project runners to project          
Clear runner caches manually          
Enable instance runners in project          
Manage CI/CD settings          
Manage job triggers          
Manage project-level CI/CD variables          
Manage project-level Secure Files          
Use environment terminals          
Delete pipelines            

Job permissions

This table shows granted privileges for jobs triggered by specific types of users:

Action Guest, Reporter Developer Maintainer Administrator Notes
Run CI job    
Clone source and LFS from current project    
Clone source and LFS from public projects    
Clone source and LFS from internal projects   Developers and Maintainers: Only if the triggering user is not an external user.
Clone source and LFS from private projects   Only if the triggering user is a member of the project. See also Usage of private Docker images with if-not-present pull policy.
Pull container images from current project    
Pull container images from public projects    
Pull container images from internal projects   Developers and Maintainers: Only if the triggering user is not an external user.
Pull container images from private projects   Only if the triggering user is a member of the project. See also Usage of private Docker images with if-not-present pull policy.
Push container images to current project    
Push container images to other projects          
Push source and LFS          

Group members permissions

Any user can remove themselves from a group, unless they are the last Owner of the group.

The following table lists group permissions available for each role:

Action Guest Reporter Developer Maintainer Owner Notes
Add an issue to an epic You must have permission to view the epic and edit the issue.
Add/remove child epics You must have permission to view the parent and child epics.
Browse group  
Pull a container image using the dependency proxy  
Pull a container registry image Guests can only view events based on their individual actions.
View group wiki pages Guests: In addition, if your group is public or internal, all users who can see the group can also see group wiki pages.
View Insights  
View Insights charts  
View Issue analytics  
View Contribution analytics  
View group epic  
View value stream analytics  
Create/edit group epic    
Create/edit/delete epic boards    
Create/edit/delete group milestones    
Create/edit/delete iterations    
Manage group labels    
Pull packages    
View Group DevOps Adoption    
View Productivity analytics    
View metrics dashboard annotations    
Publish packages      
Remove a container registry image      
Create and edit group wiki pages      
Create project in group     Developers, Maintainers and Owners: Only if the project creation role is set at the instance level or the group level.

Developers: Developers can push commits to the default branch of a new project only if the default branch protection is set to “Partially protected” or “Not protected”.
Create/edit/delete metrics dashboard annotations      
Use security dashboard      
View group Audit Events     Developers and Maintainers can only view events based on their individual actions.
Delete group wiki pages      
Create subgroup       Maintainers: Only if users with the Maintainer role are allowed to create subgroups.
Create/edit/delete Maven, generic, NuGet, and Terraform Modules package duplicate settings          
Create/edit/delete dependency proxy cleanup policies          
Delete packages        
Edit epic comments (posted by any user)        
Enable/disable a dependency proxy          
Enable/disable package request forwarding          
Fork project into a group        
Manage group approval rules (group settings)        
Manage group push rules        
View group runners        
View/manage group-level Kubernetes cluster        
List group deploy tokens          
Change group visibility level          
Create and manage compliance frameworks          
Create/Delete group deploy tokens          
Delete group          
Delete group epic          
Disable notification emails          
Edit SAML SSO         Does not apply to subgroups
Edit group settings          
Configure project templates          
Filter members by 2FA status          
Manage subscriptions, and purchase storage and compute minutes          
Manage group level CI/CD variables          
Manage group members          
Manage group runners          
Manage group-level custom roles          
Migrate groups          
Purge the dependency proxy for a group          
Share (invite) groups with groups          
View Billing         Does not apply to subgroups
View 2FA status of members          
View group Usage Quotas page         Does not apply to subgroups

Subgroup permissions

When you add a member to a subgroup, they inherit the membership and permission level from the parent groups. This model allows access to nested groups if you have membership in one of its parents.

For more information, see subgroup memberships.

Users with Minimal Access

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
History
  • Support for inviting users with Minimal Access role introduced in GitLab 15.9.

Users with the Minimal Access role do not:

  • Automatically have access to projects and subgroups in that root group.
  • Count as licensed seats on self-managed Ultimate subscriptions or any GitLab.com subscriptions, provided the user has no other role anywhere in the instance or in the GitLab.com namespace.

Owners must explicitly add these users to the specific subgroups and projects.

You can use the Minimal Access role to give the same member more than one role in a group:

  1. Add the member to the root group with a Minimal Access role.
  2. Invite the member as a direct member with a specific role in any subgroup or project in that group.

Because of an outstanding issue, when a user with the Minimal Access role:

  • Signs in with standard web authentication, they receive a 404 error when accessing the parent group.
  • Signs in with Group SSO, they receive a 404 error immediately because they are redirected to the parent group page.

To work around the issue, give these users the Guest role or higher to any project or subgroup within the parent group.