Permissions and roles
DETAILS: 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 |
✓ | ✓ | ✓ | ✓ | ||
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 |
✓ | |||||
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: 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: 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 | ✓ | ✓ | ||||
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 |
✓ | ✓ | ✓ | ✓ | ||
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 |
✓ | ✓ | ✓ | ✓ |
Application Security
Project permissions for Application Security features including dependency management, security analyzers, security policies, and vulnerability management.
Action | Guest | Reporter | Developer | Maintainer | Owner | Notes |
---|---|---|---|---|---|---|
View licenses in dependency list | ✓ | ✓ | ✓ | |||
View dependency list | ✓ | ✓ | ✓ | |||
View vulnerability report | ✓ | ✓ | ✓ | |||
View security dashboard | ✓ | ✓ | ✓ | |||
Create issue from vulnerability finding | ✓ | ✓ | ✓ | |||
Manually create a vulnerability | ✓ | ✓ | ✓ | |||
Create and run on-demand DAST scans | ✓ | ✓ | ✓ | |||
Create, edit, delete individual security policies | ✓ | ✓ | ✓ | |||
Create a CVE ID Request | ✓ | ✓ | ||||
Change vulnerability status | ✓ | ✓ | The admin_vulnerability permission was removed from the Developer role in GitLab 17.0. |
|||
Create or assign security policy project | ✓ | |||||
Manage security configurations | ✓ |
Compliance
Project permissions for compliance features including compliance center, audit events, compliance frameworks, and licenses.
Action | Guest | Reporter | Developer | Maintainer | Owner | Notes |
---|---|---|---|---|---|---|
View allowed and denied licenses in MR | ✓ | ✓ | ✓ | ✓ | ✓ | 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 have at least the Reporter role, even if the project is internal. Users with the Guest role on GitLab.com are able to perform this action only on public projects because internal visibility is not available. |
View audit events | ✓ | ✓ | ✓ | Users can only view events based on their individual actions. | ||
View licenses in dependency list | ✓ | ✓ | ✓ | |||
Create, edit, and delete license approval policies | ✓ | ✓ | ✓ | |||
Manage audit streams | ✓ |
Repository
Project permissions for repository features including source code, branches, push rules, and more:
Action | Guest | Reporter | Developer | Maintainer | Owner | Notes |
---|---|---|---|---|---|---|
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. |
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. |
View a commit status | ✓ | ✓ | ✓ | ✓ | ||
Create or update commit status | ✓ | ✓ | ✓ | If the branch is protected, this depends on the access given to Developers and Maintainers. | ||
Create and delete Git tags | ✓ | ✓ | ✓ | |||
Create new branches | ✓ | ✓ | ✓ | |||
Force push to non-protected branches | ✓ | ✓ | ✓ | |||
Push to non-protected branches | ✓ | ✓ | ✓ | |||
Delete non-protected branches | ✓ | ✓ | ✓ | |||
Manage protected branches | ✓ | ✓ | ||||
Delete protected branches | ✓ | ✓ | ||||
Manage protected tags | ✓ | ✓ | ||||
Manage push rules | ✓ | ✓ | ||||
Push to protected branches | ✓ | ✓ | If the branch is protected, this depends on the access given to Developers and Maintainers. | |||
Remove fork relationship | ✓ | |||||
Force push to protected branches | Not allowed for Guest, Reporter, Developer, Maintainer, or Owner. See protected branches. |
Project permissions for merge requests:
Action | Guest | Reporter | Developer | Maintainer | Owner | Notes |
---|---|---|---|---|---|---|
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. |
Create a merge request | ✓ | ✓ | ✓ | In projects that accept contributions from external members, users can create, edit, and close their own merge requests. | ||
Update a merge request including assign, review, code suggestions, approve, labels, lock and resolve threads | ✓ | ✓ | ✓ | For information on eligible approvers for merge requests, see Eligible approvers. | ||
Manage merge request settings | ✓ | ✓ | ||||
Manage merge request approval rules | ✓ | ✓ | ||||
Delete merge request | ✓ |
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.
Project Owners can do any listed action, and also can delete pipelines:
Action | Non-member | Guest | Reporter | Developer | Maintainer | 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 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 job | ✓ | ✓ | ||||
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 CI/CD variables | ✓ | |||||
Manage project Secure Files | ✓ | |||||
Use environment terminals | ✓ |
Job permissions
This table shows granted privileges for jobs triggered by specific roles.
Project Owners can do any listed action, but no users can push source and LFS together. Guest users and members with the Reporter role cannot do any of these actions.
Action | Developer | Maintainer | Notes |
---|---|---|---|
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 | ✓ | ✓ | You cannot push container images to other projects. |
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 | ✓ | ✓ | ✓ | |||
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 can 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 | ✓ | ✓ | ||||
View group runners | ✓ | ✓ | ||||
View/manage group-level Kubernetes cluster | ✓ | ✓ | ||||
Change group visibility level | ✓ | |||||
Create and manage compliance frameworks | ✓ | |||||
Create/Delete group access 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 | ||||
Map or unmap workspace cluster agents to and from a group | ✓ | |||||
View workspace cluster agents mapped to a group | ✓ | ✓ |
Application Security
Group permissions for Application Security features including dependency management, security analyzers, security policies, and vulnerability management.
Action | Guest | Reporter | Developer | Maintainer | Owner | Notes |
---|---|---|---|---|---|---|
View dependency list | ✓ | ✓ | ✓ | |||
View vulnerability report | ✓ | ✓ | ✓ | |||
View security dashboard | ✓ | ✓ | ✓ | |||
Create or assign security policy project | ✓ |
Compliance
Groups permissions for compliance features including compliance center, audit events, compliance frameworks, and licenses.
Action | Guest | Reporter | Developer | Maintainer | Owner | Notes |
---|---|---|---|---|---|---|
View audit events | ✓ | ✓ | ✓ | Users can view only events based on their individual actions. | ||
View licenses in the dependency list | ✓ | ✓ | ✓ | |||
Manage audit streams | ✓ | |||||
View the compliance center | ✓ | |||||
Manage compliance frameworks | ✓ | |||||
Assign compliance frameworks to projects | ✓ |
Repository
Group permissions for repository features including merge requests, push rules, and deploy tokens.
Action | Guest | Reporter | Developer | Maintainer | Owner | Notes |
---|---|---|---|---|---|---|
Manage merge request settings | ✓ | |||||
Manage push rules | ✓ | |||||
Manage deploy tokens | ✓ |
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
DETAILS: Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
- 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:
- Add the member to the root group with a Minimal Access role.
- Invite the member as a direct member with a specific role in any subgroup or project in that group.
Minimal access users receive 404 errors
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 in the parent group. Guest users consume a license seat in the Premium tier but do not in the Ultimate tier.