Configure Job Token scope at group level
Problem to solve
With the CI/CD job token, users can facilitate secure communication between a job (on a runner) and the GitLab instance itself (API, Container Registry, etc.). To do so, users add target projects to the allowlist at the project-level. For example, Project A
can add Project B
to the allowlist. CI/CD jobs in Project B
(the "allowed project") can now use their CI/CD job token to authenticate API calls and access Project A
.
However, users can only add one project at a time to the allowlist at the project level currently. For organisations with many projects, it is a very tedious task to add target projects one by one to an allowlist for all projects that need to be accessible with each other.
User experience goal
Users can easily grant CI_JOB_TOKEN access between multiple projects without manually adding each project to an allowlist one by one.
Proposal
To solve the problem, we could explore a way to bulk add multiple projects to an allowlist, which we could leverage the concept of groups.
One solution is to introduce CI_JOB_TOKEN settings at the group level, enabling users to add both groups and projects to an allowlist, using the same technique as at the project level.
Another potential solution idea is to allow projects to add groups to their CI_JOB_TOKEN allowlist (see issue #415519 (closed)).
Overall behaviour
- The feature is enabled by default with an empty allowlist:
-
Enabled (Toggle on):
- Allows access by other groups or projects.
- the allowlist is active.
-
Disabled (Toggle off):
- Restricts access.
- The allowlist is ignored.
-
Enabled (Toggle on):
- Users can add a group or project to the allowlist.
- When user add a group to the allowlist, the projects associated with this group will not count towards the 200-project limit.
Access control prioritisation
- Group settings can be inherited by subgroups and projects within that group.
- Subgroups and projects can override these inherited settings.
- Lower-level settings will take precedence over higher-level settings; in other words, project settings would override group settings.
Design and details
Designs
tab
Iteration
- 1st iteration: All projects inherit from the group.
- Future iteration: Improve the user experience for Job Token at gr... (&13722)
More background and context for this issue
- This issue was initially raised in 2021, and an early solution was proposed two years ago (and refined three months ago).
- A solution validation was conducted with a customer in October 2023 (See note in Dovetail).
- The Project Level limit a project's job token access is deprecated and will be removed in the 17.0 milestone.
- Related issue: Allow projects to add groups to their CI_JOB_TOKEN allow list.
- Refer to the research issue Solution validation: CI_JOB_TOKEN overall behavior for further context and scenarios in comments.
Click this to show/hide initial proposal.
Problem
With the CI job token scope it's possible to configure a target project B
to be accessible by a job token originating in project A
.
For a private project to be accessible via CI_JOB_TOKEN it must be added to the allowlist of the originating project. This could become cumbersome if an organization has many projects and would like them to be accessible from each other. Currently the user need to add each target project to the allowlist of the origin project.
Idea
To solve this problem we could perhaps enable the CI_JOB_TOKEN scope at group level using the same technique as at project level:
- when enabled at group level, a target project is considered "in scope" if the CI_JOB_TOKEN is originating in the same group.
- this allows the token to access the target project because they both belong to the same scope.
- when enabled at group level, if the target project does not belong to the same group of the CI_JOB_TOKEN's project, access is denied.
- the user needs to add the target group to the "job token scope" allowlist for it to have access.
- [optional] the user could decide not to add a whole group to the "job token scope" (if not needed) and add a single project instead.
Implementation table
Please note: this issue is currently being used to track the design progress of this work. The table below will be used to track the frontend and backend components.
--- | Issue |
---|---|
Frontend | Frontend: UI to configure job token scope at group level |
Backend | Backend: API to configure job token scope at group level |
This 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.
This 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.