Backend: Enable a ci_token permission flow for bots to work across dot-com and other shared instances securely
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.
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.
- a maintainer of project
security-botcan scan project
A(or its artifacts) for security vulnerabilities (this can happen via a scheduled pipeline that runs on
security-botproject and iterates through all the projects that
security-botuser is member)
- if auto-remediations are available, the
security-botproposes changes to the repository by pushing them to a branch and open a MR
- a pipeline runs in project
- at this point the
security-botcan't control what's running on the project
Apipeline. The CI_JOB_TOKEN could be used to impersonate
security-botand access other private repositories
Limiting the "inbound requests with CI_JOB_TOKEN" only to allowlisted projects should block such abuses.
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
Add expected impact to Maintainer (40) members
Add expected impact to Owner (50) members
Update the documentation to reflect the new workflow/UX.
Availability & Testing
Feature Usage Metrics
- We would to track that users are viewing the page, adding, removing for both the inbound and outbound access.
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
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.
- Add to the CI_JOB_TOKEN interface the ability to set allowed projects that can use the secure token
- In the
Scenariothis is the maintainer of project
security-botto the project in the interface shown in the design.
- In the
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: #346298[secure-bot-flow.png]
- Backend: Database migrations to setup project allow list and new toggle setting
- Add a column to
inboundrealationships. !98673 (merged)
- Add a column to
project_ci_cd_settingsto toggle the setting
- Consider renaming the setting
- Add a column to
- 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
|!98673 (merged)||Add a column to
|!99032 (merged)||Add a column to
|!99165 (merged)||Allow toggling the inbound job token scope|
|!99166||Add project to inbound scope (Graphql and REST)|
|!105926||migration updating uniqueness|
|TODO||Remove project from scope (Graphql and REST)|
|TODO||Backend: Read the inbound scope allow list|
|TODO||Core logic to restrict access based on the allow list|
|TODO||Flag removal & documentation (will require frontend complete)|