Remove limit CI_JOB_TOKEN access scope (#383084) · Issues · GitLab.org / GitLab

Remove limit CI_JOB_TOKEN access scope

GitLab customers with an active subscriptions can reach out to [GitLab Support](https://support.gitlab.com/) 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](https://gitlab.com/gitlab-org/gitlab/-/issues/395708#understanding-this-change) 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 - This can also be checked via the [Get a project’s CI/CD job token access settings](https://docs.gitlab.com/17.10/api/project_job_token_scopes/#get-a-projects-cicd-job-token-access-settings) API endpoint. If the `inbound_enabled ` value for a project is `true`, the project is impacted. - Self-managed users can use a dry-mode/preview run of [the Rake task](https://docs.gitlab.com/ci/jobs/ci_job_token/#with-a-rake-task) to determine all impacted projects. ### 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 :warning: On GitLab.com, this will occur during [window 1](https://docs.gitlab.com/update/breaking_windows/#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](https://docs.gitlab.com/ci/jobs/ci_job_token/#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](https://docs.gitlab.com/ci/jobs/ci_job_token/#with-the-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](https://docs.gitlab.com/administration/settings/continuous_integration/#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](https://docs.gitlab.com/ci/jobs/ci_job_token/#auto-populate-a-projects-allowlist). You can populate allowlists for an individual project [with the UI](https://docs.gitlab.com/ci/jobs/ci_job_token/#with-the-ui). Self-managed customers can use [a Rake task](https://docs.gitlab.com/ci/jobs/ci_job_token/#with-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](https://support.gitlab.com/) 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` 1. `Mutations::Ci::JobTokenScope::RemoveProject` `direction` 1. `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](https://docs.gitlab.com/ci/jobs/ci_job_token/#limit-your-projects-job-token-access-deprecated) 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](https://docs.gitlab.com/update/breaking_windows/#window-3), we rollout the feature flag - we use the same feature flag for frontend and backend - [Rollout issue](https://gitlab.com/gitlab-org/gitlab/-/issues/537186) - [ ] 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](https://docs.gitlab.com/ci/jobs/ci_job_token/#limit-your-projects-job-token-access-deprecated). If it is a `ops` feature flag, then this MR is just to keep the Feature flag enabled by default

issue