Backend: Enable a ci_token permission flow for bots to work securely
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 thesecurity-bot
as developer -
security-bot
can scan projectA
(or its artifacts) for security vulnerabilities (this can happen via a scheduled pipeline that runs onsecurity-bot
project and iterates through all the projects thatsecurity-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
assecurity-bot
user. - at this point the
security-bot
can't control what's running on the projectA
pipeline. The CI_JOB_TOKEN could be used to impersonatesecurity-bot
and access other private repositories
Limiting the "inbound requests with CI_JOB_TOKEN" only to allowlisted projects should block such abuses.
Intended users
Further details
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
Documentation
Update the documentation to reflect the new workflow/UX.
Availability & Testing
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.
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.
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 projectA
addingsecurity-bot
to 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]
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 theoutbound
andinbound
realationships. !98673 (merged) - Add a column to
project_ci_cd_settings
to toggle the settinginbound
inbound_job_token_scope_enabled
- Consider renaming the setting
job_token_scope_enabled
tooutbound_job_token_scope_enabled
- 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
Backend MR's
MR | MR description |
---|---|
!98673 (merged) | Add a column to ci_job_token_project_scope_links with the outbound and inbound direction
|
!99032 (merged) | Add a column to project_ci_cd_settings to toggle the setting inbound inbound_job_token_scope_enabled
|
!99165 (merged) | Allow toggling the inbound job token scope |
!100303 (merged) | Rename project.ci_job_token_scope_enabled to project.ci_outbound_job_token_scope_enabled
|
!102805 (merged) | Ensure existing module Ci::JobToken::Scope only uses outbound direction |
!99166 (merged) | Add project to inbound scope (Graphql) |
!105926 (merged) | migration updating uniqueness |
!110662 (closed) and !110669 (merged). | Remove project from scope (Graphql) |
!99166 (merged) | Backend: Read the inbound scope allow list |
!106902 (merged) | Core logic to restrict access based on the allow list |
!109915 (merged) | documentation (will require frontend complete) |
!111694 (merged) | Flag removal |