Skip to content

Remove limit CI_JOB_TOKEN access scope

GitLab customers with an active subscriptions can reach out to GitLab Support when encountering unexpected problems with this change.

Understanding this change

The notes below are about restricting access to a project via the CI_JOB_TOKEN allowlist and the upcoming enforcement of that. At the same time we'll remove the ability to restrict access from a project that was briefly available before 16.0 – see these notes for details.

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 Authorized groups and projects setting
  4. If the All groups and projects option is selected, this project is impacted

What does impact from this change look like?

The exact impact is different for GitLab.com, and for GitLab Dedicated & self-managed instances.

GitLab.com

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

The project Job token permissions setting will no longer be available and all projects behave as if Only this project and any groups and projects in the allowlist was selected. This means that other projects that attempt to authenticate access to a project via the CI_JOB_TOKEN now have to be on that project's allowlist.

To avoid disruption, the allowlist of these projects will automatically be populated with the projects/namespaces from the Job token authentication log. This log contains any authentication events from the last 30 days that happened while All groups and projects was the selected option. Effectively this means that access to projects will change from "All access allowed" to "Only explicitly granted access allowed" with explicit access automatically being granted to everything that made use the "All access allowed" approach before.

You can remove the automatically added entries from your allowlist in the same UI that allows you to add those entries manually. Note that this is likely going to cause disruption in your pipelines.

GitLab Dedicated and self-managed instances

On GitLab Dedicated and self-managed instances, users have access to the GitLab Admin area. Here you can globally configure the Job token permissions in Settings > CI/CD. Expand the Job token permissions section to find the Enable and enforce job token allowlist for all projects toggle.

When your instance is upgraded to GitLab 18.0, a database migration will enable this toggle – regardless of your current setting. No changes will be made to any project's Job token permissions setting. However, with the Admin area toggle enabled, individual project Job token permissions settings are no longer visible and all projects behave as if Only this project and any groups and projects in the allowlist was their selected option. Neither on GitLab Dedicated nor on self-managed instances will allowlist population be performed automatically (as on GitLab.com).

Other projects that attempt to authenticate access to a project via the CI_JOB_TOKEN now have to be on that project's allowlist. Effectively this means that access to projects will change from "All access allowed" to "Only explicitly granted access allowed".

You can disable the Enable and enforce job token allowlist for all projects toggle in the Admin area after upgrading to GitLab 18.0. This will result in the behavior from before the upgrade – projects may chose either All groups and projects or Only this project and any groups and projects in the allowlist for the project level Job token permissions setting and this choice will be respected.

Alternatively, leave the Enable and enforce job token allowlist for all projects toggle in the Admin area enabled and use the options to Auto-populate a project’s allowlist. You can populate allowlists for an individual project with the UI. Self-managed customers can use a Rake task to automatically populate allowlists for all projects.

General notes

This is an additional layer of security, it does not replace the need for properly managed user permissions on the user who starts the pipeline/job to which a CI_JOB_TOKEN belongs.

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. Populate allowlists ahead of time
  3. Change all project Job token permissions settings to Only this project and any groups and projects in the allowlist

Alternatively, do nothing and revert the Admin area Enable and enforce job token allowlist for all projects toggle after upgrading.

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

Problem to solve

Managing access for both inbound and outbound permissions together for limited CI_JOB_TOKEN requires coordination across projects and project owners may not know of each other at all so revert to creating an email or opening an issue, if they can, in the project they need to access.

Proposal

Remove capability for users to Limit CI_JOB_TOKEN access scope

Intended users

Feature Usage Metrics

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.

Implementation tasks

Backend

  • We can remove all references to direction from the Scope and Allowlist classes
  • We can create a data migration to remove all outbound Ci::JobToken::ProjectScopeLink's from the table.
  • We can remove the direction column on Ci::JobToken::ProjectScopeLink related table and adjust the unique index on that table
  • In 16.0, we can, deprecate but not remove certain arguments and fields from the graphql api, that's because we need a deprecation notice a few milestones before removal. https://docs.gitlab.com/ee/development/deprecation_guidelines/
    1. Mutations::Ci::JobTokenScope::RemoveProject direction
    2. Mutations::Ci::JobTokenScope::RemoveProject direction
    3. Types::Ci::JobTokenScopeType outbound_allowlist
  • We will need to ensure all graphql documentation no longer references outbound as much as possible without fully removing the direction argument and outbound enum.

Frontend

  • Remove outbound from token_access_app.vue
  • Delete outbound_token_access.vue
  • Delete outbound mutations
  • Delete outbound queries
  • Delete outbound spec
  • Update token access app spec
  • Once inbound is default direction update related mutations
  • Remove inbound naming prefix on mutations/queries (optional)

Remaining Items To Do to disable the feature

  • MR behind a Feature Flag in which we disable the already deprecated product feature of Limiting CI_JOB_TOKEN access scope. Update the deprecated feature documentation to add the Feature flag reference. Hide section in the UI. Get this MR reviewed and deployed
  • In the breaking change window from May 5th to 7th, we rollout the feature flag - we use the same feature flag for frontend and backend - Rollout issue
  • After the feature disabling is deemed stable, if it is a derisk Feature flag, then create an MR to cleanup the feature flag checks and conditionals in both frontend and backend. Also update docs. We need to remove the section on the feature that we are disabling. If it is a ops feature flag, then this MR is just to keep the Feature flag enabled by default
Edited by Jayakrishnan Mallissery