Skip to content

Disable limit CI_JOB_TOKEN scope

Understanding this change

Does this change impact you?

The steps for users on a SaaS platform (GitLab.com, GitLab Dedicated) and for self-managed to check whether they will be impacted are:

  1. Browse to the project you want to check
  2. Navigate to the project's CI/CD settings
  3. In the Job token permissions section, look at the Limit access from this project (Deprecated) toggle
  4. If this toggle is enabled, this project is impacted

  • This can also be checked via the Get a project’s CI/CD job token access settings API endpoint. If the outbound_enabled value for a project is true, the project is impacted.

  • Self-managed users can retrieve a list of all impacted project IDs with a PostgreSQL query:

    SELECT project_id FROM project_ci_cd_settings WHERE job_token_scope_enabled = True;

What does impact from this change look like?

Any projects that currently still have the Limit access from this project (Deprecated) toggle enabled will have it disabled as part of the upgrade to GitLab 18.0. The toggle will no longer be visible. This means that no restriction will be imposed on which other projects your project can access via the CI_JOB_TOKEN. This change will not cause permission issues in pipelines, as it widens access.

⚠️ On GitLab.com, this will occur during window 1 (April 21 - 23, 2025 from 09:00 UTC to 22:00 UTC) – before the release of GitLab 18.0.

Note that other projects may restrict which projects can access them via their CI/CD job token allowlist in the same settings section. See the corresponding change for details.

How to prepare for this change?

The steps for users on a SaaS platform (GitLab.com, GitLab Dedicated) and for self-managed to prepare for this change are:

  1. Determine impacted projects
  2. Disable the Limit access from this project (Deprecated) toggle ahead of time

Alternatively, letting this change happen automatically as part of the GitLab 18.0 upgrade will not cause any interruptions of service and will be a reasonable choice for most users.

GitLab customers with an active subscriptions can reach out to GitLab Support when encountering problems with the guidance above.

Problem

We want to retire the outbound job token scope since customers preferred the inbound scoping during customer validation.

However, simply removing the functionality entirely would make our customers using the feature abruptly less secure with a larger scope of projects their projects can access via the CI_JOB_TOKEN than they wanted to allow.

Solution

In this issue we can

  • disable the ability to add new projects to the "limit CI_JOB_TOKEN scope" (outbound) in the backend
  • disable the ability to toggle the scope on in the frontend
  • The UI should not be removed, but rather grayed out to show if the toggle is on or off.
  • We should add a help text that includes "Limit CI_JOB_TOKEN scope is deprecated and will be removed in a future milestone. Configure the CI_JOB_TOKEN allowlist. For more information, see our documentation"

We will still:

  • enforce permissions based on the existing projects in the inbound allowlist.

This will keep customers from adding more data this way reducing the scope of data that needs to be migrated or manually changed in or around the %17.0 milestone when the feature will be completely removed.

UI changes

  • Warning that Limit CI_JOB_TOKEN access is deprecated and adding CI_JOB_TOKEN project allowlist scopes is disabled and cannot be or be enabled.
  • Disable the toggle if it's currently off.
    • Add warnings that turning off Limit CI_JOB_TOKEN access is a permanent change
  • Disable the input and button for adding a project but still show the project list.
  • UI should still be visible but "grayed out"

Implementation

Backend

Mutations::Ci::JobTokenScope::AddProject

  • We can add a feature flag and that removes the :outbound parameter when it's specified as direction.
  • We can make the default parameter :inbound if none is specified.
  • We can deprecate the :direction argument entirely but not yet remove it.

Mutations::Ci::ProjectCiCdSettingsUpdate

  • We can add a feature flag and that removes the job_token_scope_enabled argument if it's being set to true.
  • We can deprecate but not remove the job_token_scope_enabled argument

Breaking User impact

Users who were using the GraphQL API to add a project to the Limit CI_JOB_TOKEN access allowlist will no longer be able to.

If the direction parameter is left out of the CiJobTokenScopeAddProject mutation then the project will be added to the Allow access to this project with a CI_JOB_TOKEN allowlist. Previously it would have been added to the Limit CI_JOB_TOKEN access allowlist.

Users will no longer be able to turn on the setting that enforces Limit CI_JOB_TOKEN access.

Once users turn off the Limit CI_JOB_TOKEN access scope they cannot go back to using it and must instead configure the same permissions using the Allow access to your project with a job token scope.

Once users remove a project from Limit CI_JOB_TOKEN access allowlist they cannot re-add it and must instead configure the same permissions using the Allow access to your project with a job token allowlist.

What's not changing

Users projects will still be secured as documented by the Limit CI_JOB_TOKEN access scope documentation.

Edited by Manuel Grabowski