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