• Roles
• Project members permissions
• GitLab CI/CD permissions
  • Job permissions
• Group members permissions
  • Subgroup permissions
• Users with Minimal Access
• Related topics

Permissions and roles

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. In GitLab 14.8 and earlier, the role is inherited for a group’s projects.
• 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.
• In GitLab 14.9 and later, 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:

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.

Job permissions

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

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:

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

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.

Related topics

• Custom roles
• The GitLab principles behind permissions
• Members
• Customize permissions on protected branches
• LDAP user permissions
• Value stream analytics permissions
• Project aliases
• Auditor users
• Confidential issues
• Container registry permissions
• Release permissions
• Read-only namespaces