<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Release notes The CI_JOB_TOKEN CI/CD variable makes API calls more intuitive within CI/CD jobs, enabling advanced automation. For example, the token can be used with bot automation projects that run pipelines in other projects. The token is short-lived, but in an effort to make its usage even more secure we are adding a setting that lets you list the exact projects that can use their CI job token to access your project. If a token from another project is used to access your project it will be denied access to the API. In the bot automation example, it gives you additional control over the exact projects that can access yours and an added layer of security when using the CI_JOB_TOKEN CI/CD variable. This setting is currently disabled by default to avoid impacting existing projects but we strongly recommend enabling it in all your existing projects. ### Problem to solve A security bot in a specific project (security-bot-project) lives in an instance and needs to be permitted to have access to target projects. Ideally, we originally wanted to use a `Limit CI_JOB_TOKEN scope` but this is to discuss the specific renovabot and secure-bot use cases as they seem to deviate slightly from that. Constraints: The bot should get permissions for each specific project, but NOT across projects. Why? this bot, on gitlab.com for instance is owned by GitLab and will have access to many different customers and we don't want one customer to be able to leak or steal information via the bot's token from any other/ to any other customers. This should be configured to work however on any instance for security / legal / compliance reasons projects may need to be isolated and protected from one another. So a target project needs to be able to give access to the security-bot via a token for a level they specify and NOT have any maintainer/etc access to the security-bot project. The target project user should also be unable to leverage the token of the bot when it runs in their project against any other project the bot has or had access to. We also would need maintainers of target project to be able to see, and revoke, the security-bot's access at any time via an allowlist. ### Scenario * a maintainer of project `A` adds the `security-bot` as developer * `security-bot` can scan project `A` (or its artifacts) for security vulnerabilities (this can happen via a scheduled pipeline that runs on `security-bot` project and iterates through all the projects that `security-bot` user is member) * if auto-remediations are available, the `security-bot` proposes changes to the repository by pushing them to a branch and open a MR * a pipeline runs in project `A` as `security-bot` user. * at this point the `security-bot` can't control what's running on the project `A` pipeline. The CI_JOB_TOKEN could be used to impersonate `security-bot` and access other private repositories Limiting the "inbound requests with CI_JOB_TOKEN" only to allowlisted projects should block such abuses. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) * [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor) --> ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> ### Permissions and Security * [ ] Add expected impact to members with no access (0) * [ ] Add expected impact to Guest (10) members * [ ] Add expected impact to Reporter (20) members * [ ] Add expected impact to Developer (30) members * [x] Add expected impact to Maintainer (40) members * [x] Add expected impact to Owner (50) members <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? Consider adding checkboxes and expectations of users with certain levels of membership https://docs.gitlab.com/ee/user/permissions.html * [ ] Add expected impact to members with no access (0) * [ ] Add expected impact to Guest (10) members * [ ] Add expected impact to Reporter (20) members * [ ] Add expected impact to Developer (30) members * [ ] Add expected impact to Maintainer (40) members * [ ] Add expected impact to Owner (50) members --> ### Documentation Update the [documentation](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#limit-gitlab-cicd-job-token-access) to reflect the new workflow/UX. ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### Available Tier * Free * Premium * Ultimate ### Feature Usage Metrics - We would to track that users are viewing the page, adding, removing for both the inbound and outbound access. <!-- How are you going to track uage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md --> ### What does success look like, and how can we measure that? - We would expect to see some users utilizing this within 30 days of GA on gitlab.com ### What is the type of buyer? ### Is this a cross-stage feature? ### Links / references https://gitlab.com/gitlab-org/gitlab/-/issues/328553#note_655444592 <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> # Proposal - Add to the CI_JOB_TOKEN interface the ability to set allowed projects that can use the secure token - In the `Scenario` this is the maintainer of project `A` adding `security-bot` to the project in the interface shown in the design. ### User experience goal An owner/maintainer of a project can add an external project to the list of projects allowed to use secure `CI_JOB_TOKEN`. See the design: https://gitlab.com/gitlab-org/gitlab/-/issues/346298/designs/secure-bot-flow.png ## Technical Proposal ### Backend * Backend: Database migrations to setup project allow list and new toggle setting - Add a column to `ci_job_token_project_scope_links` with the `outbound` and `inbound` realationships. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/98673 - Add a column to `project_ci_cd_settings` to toggle the setting `inbound` `inbound_job_token_scope_enabled` - Consider renaming the setting `job_token_scope_enabled` to `outbound_job_token_scope_enabled` * Backend: Allow toggle the scope/setting (graphql and REST) * Backend: Allow add the project to the scope (Graphql and REST) * Backend: Remove project from scope (Graphql and REST) * Backend: Core logic to restrict access based on the allow list * Backend: Flag rollout and removal ### Backend MR's | MR | MR description | | ------ | ------ | | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/98673 | Add a column to `ci_job_token_project_scope_links` with the `outbound` and `inbound` `direction` | | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/99032 | Add a column to `project_ci_cd_settings` to toggle the setting `inbound` `inbound_job_token_scope_enabled` | | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/99165 | Allow toggling the inbound job token scope | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/100303 | Rename `project.ci_job_token_scope_enabled` to `project.ci_outbound_job_token_scope_enabled` | | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/102805 | Ensure existing `module Ci::JobToken::Scope` only uses outbound direction | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/99166 | Add project to inbound scope (Graphql) |https://gitlab.com/gitlab-org/gitlab/-/merge_requests/105926 | migration updating uniqueness | | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/110662 and https://gitlab.com/gitlab-org/gitlab/-/merge_requests/110669. | Remove project from scope (Graphql) |!99166| Backend: Read the inbound scope allow list | | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106902 | Core logic to restrict access based on the allow list | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/109915 | documentation (will require [frontend](https://gitlab.com/gitlab-org/gitlab/-/issues/375782) complete) | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111694 | Flag removal