Skip to content

Configure Job Token scope at group level

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

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

👉 See the most updated design by clicking the Designs tab

Iteration

More background and context for this issue

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.

Edited by 🤖 GitLab Bot 🤖