Enable secure bot authorization workflows with CI_JOB_TOKEN
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.
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 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
User experience goal
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 -
Maintainer (40) members -
Owner (50) members