Blog DevSecOps Platform How to tailor GitLab access with custom roles
February 13, 2024
5 min read

How to tailor GitLab access with custom roles

Find out the current capabilities of custom roles and what's to come, including initial grouping of permissions and templating from default roles.

customize - cover image

At GitLab, we knew we had a big problem to solve. Our existing, default user roles were becoming roadblocks for our customers. The default roles, such as Guest, Reporter, Developer, Maintainer, and Owner, offer a predefined set of permissions that cannot be customized. Customers were forced to fit their specific needs into the existing roles, leading to either overly permissive access, which is a security risk, or under-privileged access, which required administrator overhead to temporarily elevate privileges of a user in order to perform a task, and remember to move them back down to their normal role afterwards.

In 15.9, we released our first iteration for customizable roles within GitLab. It allowed customers to do one simple thing: Give the Guest user the ability to view code, without consuming a seat. Our hope was to give our customers the ability to add more privilege to the Guest role, if they so desired, while retaining the benefit of free Guest users with an Ultimate subscription.

Our MVC was released almost a year ago now, so we wanted to provide an update on the progress we’ve made with customizable roles and an idea of where we are headed.

Custom roles - image 1

Custom roles - image 2

Looking at the next iteration of custom roles

As we build toward the next iteration of custom roles and permissions, we have gathered a lot of feedback from the MVC. Two common themes that have been uncovered are:

  • reducing privilege of Developer, Maintainer, and Owner roles
  • a wide range of access permutations

Here's how we plan to address these challenges.

Consistent CRUD model

If you have designed role-based access control (RBAC) in Google Cloud Platform (GCP) or Kubernetes, you may have appreciated the predictable permission verbs on resource access. As we continue to build out the next groupings of permissions for custom roles, the permissions will follow a consistent Create, Read, Update, and Delete (CRUD) model so you can predictably design your resource access within your organization.

If we examine the table below, “Manage” would be given to select few in the department or organization, whereas "Write" and "View" would be a common contributor to that resource.

Permission Description
Manage Full CRUD operations on resources. Plus configuring the settings of the resource. Assumes Write/View/Delete
Write Add or update the resource. Assumes View
View View the resource
Delete Delete the resource. Assumes View

Below is a concrete example of permissions related to registries. While this table is coarse-grained as this groups all registry types together at first, this can become fine-grained over time by pulling out each registry type as requested.

Permission Description
Manage CRUD operations on objects, including Registries, Proxy, Cleanup Policies, along with managing the settings
Write Ability to push a container, package, or terraform module to registry
View Ability to view, retrieve, and pull registry objects and metadata on repositories and images
Delete Ability to delete registry objects and metadata

Remove default role dependency

During the custom role creation process, starting with a base default role can be a quick way to add permissions, but it’s limiting when reducing only one or two permissions from Maintainer or Owner. The next iteration will allow you to build your own custom role without the predefined permissions of default roles allowing for maximum flexibility.

Build your own role

Building a custom role in a system should account for the number of permutations while isolating access for those in strict environments. As we group these resources, we are factoring in that there are a wide range of themes including project management, development, security, and operations.

Below is a sample of groupings with a permission selection that could apply to a developer. These resource groups may become finer over time based on requests.

custom roles - image 3

Building a role from a template

You may have experienced building permission sets as a starting point to simplify the assignment of user access. As you build out a custom role, you could start with a template that copies predefined permissions from a default role or specific user types such as a Project Manager.

How to contribute

We value your feedback and there are multiple ways to contribute:

  • We created a “build your own role” survey to understand how an organization would create a least privilege user in GitLab. Here is a survey link to validate our initial assumptions on permission groupings.
  • Would you like to submit ideas or share feedback based on custom roles? Here is the feedback issue.

Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert