<!-- 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 --> <!-- 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 <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> 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 be accessed with your project's CI job token. If the token is used to try to access other projects, it will be denied access to the API. In the bot automation example, it gives you additional control over the exact projects your bot will have access to and an added layer of security when using the CI_JOB_TOKEN CI/CD variable. This setting is enabled by default for all new projects, and we strongly recommend enabling it in all your existing projects. ### Problem to solve I need a secure way to enable a customer to authorize a bot to do work on their behalf without compromising all customers who use the bot. Many users leverage the CI_JOB_TOKEN to do this, although when a bot uses a ci_token to do things like auto-remediation (make an mr, merge it) it is able to leak/be compromised in such a way that one customer can maliciously grab information it leaks and then use the to get any other customer (who has authorized the bot) repo/code. ### 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) --> * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> Bots should be able to use the CI_JOB_TOKEN without fear of leaking data or information. ### Proposal Introduce a mechanism (when enabled via project settings) that limits the use of CI_JOB_TOKEN to the project where it originated from. By default, with this setting on, the CI_JOB_TOKEN won't be used outside the project's scope. However, project maintainers/owners can add other projects to the CI_JOB_TOKEN scope. This way the token can be used across a list of selected projects. For example, to trigger multi-project pipelines Introduce a section `Token access` in the projects settings where owners/maintainers can: * Introduce a setting toggle to limit job token access(a more secure behaviour) * To avoid breaking anything, this option will come unchecked for all existing projects * For new projects this setting should come checked so limiting access for job tokens(initially being limited to the native project) becomes the default behaviour * Users are allowed to add/remove projects for the CI_JOB_TOKEN scope | Design Proposal | | -------| |  | ### Permissions and Security Following roles have access to the setting * [ ] Guest (10) members * [ ] Reporter (20) members * [ ] Developer (30) members * [x] Maintainer (40) members * [x] Owner (50) members