The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Govern |
| Maturity | Viable |
| Content Last Reviewed | 2024-10-28 |
This direction page describes GitLab's plans for the permissions category that supports the following features:
This direction page is a work in progress, and everyone can contribute:
This page belongs to the Authorization group and is maintained by the Product Manager, Joe Randazzo.
The Authorization team will be addressing critical gaps in the permission category by focusing on enhancing support for custom roles, token permissions, and granular permissions on the admin page. The team's mission is to enable principle of least privielge, improve efficiency by access, and streamline compliance.
The Permissions category does not include Login, SAML, LDAP, Enterprise Users, User Management, or Tokens. These features can be found in the Authentication group.
Customers encounter several permission challenges while operating in GitLab including:
Customers, especially those in regulated environments expect to be able to reduce overprivileged access. The default roles including Owner and Maintainer for groups and projects can access a long list of settings that can lead to misconfiguration or abuse.
The Admin area for self-managed installations has many centralized views that makes it easy to quickly troubleshoot or report on metrics. Customers have several teams such as platform, support, or leadership that require access to the Admin Area to perform their job. This can lead to overprivileged access, inefficiencies in internal access requests, and negatively impact operations.
Customers have unique permission requirements ranging from separation of duties to adding or removing access from a default role. Examples include separating pipeline permissions from push/merge, permissions for project planning, and many more. As a result, various workarounds are suggested such as creating separate projects that results in isolated workflows and a disjointed user experience.
Tokens by default come with limited scopes and are often overprivileged with the api scope. In the event that a token is leaked, that token has a large blast radius to GitLab resources with potential for misconfiguration or abuse.
Job tokens are the preferred token in CI/CD workflows given its ephemeral nature. Today, the job token permissions are based on the user role who triggered the pipeline. Customers prefer to narrowly define the access to specific resources. In addition, the lack of API support for job tokens have pushed users to rely on long-lived tokens or group tokens that have security implications.
Internal customers or product groups do not have the ability to quickly add permissions to tokens. This makes it difficult for teams to prioritize and implement in their roadmap.
In FY25, we are planning to focus on the following Product Themes:
Drive Use Case Adoption to Fully Realize Value by continued expansion of user permissions:
With the customer challenges in mind, we will address the following:
See our prioritized roadmap in detail here.
Default roles are available for all tiers while free Guest users are for the Ultimate tier only.
Custom roles serve the need for Large Enterprise customers, Mid-Market customers, and those who operate in regulated industries such as Financial, Healthcare, or Public Sector. This feature is available for Ultimate tier only.
