Add groups to CI_JOB_TOKEN allowlist, groups validation implementation
Original issue: #435903 (closed)
POC MR: !143106 (closed)
What does this MR do and why?
The current configuration for CI_JOB_TOKEN
permissions relies on the project allow list, where permitted projects can be specified. The primary objective of the original issue is to expand this functionality by enabling permissions for CI_JOB_TOKEN
on specific projects through group associations.
- Inject to
Ci::JobToken::Scope
inbound_accessible?
method, a condition `group_accessible?(accessed_project) behind a feature flag - Implement
group_accessible
with the scope validation by matchingcurrent_group
ofcurrent_project
, withtarget_group
iterated fromCi::JobToken::GroupScopeLink
of the accessible project allow list, more details - Add a feature flag
group_scope_link_allowlist
group_accessible?
group CI_JOB_TOKEN validation implementation:
The entire process of validating the CI_JOB_TOKEN
relies on the idea that we execute pipelines on the current_project and assess permissions to determine if we can reach the accessible_project through the CI_JOB_TOKEN
. The process of confirming whether the current_project
can access the accesed_project
based on current_project
group operates like this: we construct a hierarchy of all parent groups on the current_project
, such as current_project_group1
-> current_project_parent_groupA_of_group1
, and if any of the current_project
groups in this list are on the allow list for the accessed_project
groups, access will be granted.
To facilitate a smoother review process, the implementation has been divided into four iterations:
Iteration plan
- Database design of group list table and model - job_token/group_scope_link - (MR: !142749 (merged))
-
Add into
app/models/ci/job_token/group_scope_link.rb
andapp/models/ci/job_token/allowlist.rb
groups validation together with inbound lists, behind a feature flaggroup_scope_link_allowlist
👈 you are here - GraphQL implementation (MR: !143132 (merged))
- REST API implementation
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
How to set up and validate locally
- Enable a FF: ::Feature.enable(:ci_job_token_groups_allowlist)
- Create for example
private_source_project
on theprivate_source_group
- Create a
private_target_group
- Create a
private_target_project
in theprivate_target_group
- Generate an artifact on
private_source_project
by creating.gitlab-ci.yml
create_artifact:
script:
- echo "artifacts data" > artifact.txt
artifacts:
paths:
- artifact.txt
- Add manually a group into groups allowlist:
Ci::JobToken::GroupScopeLink.create(source_project: private_source_project, target_group: private_target_group, added_by: user)
- Run a pipeline on
private_target_project
with.gitlab-ci.yml
artifact_download:
script:
- echo "test 11"
- 'curl --location --output artifacts.zip "http://gdk.test:3000/api/v4/projects/47/jobs/10743/artifacts?job_token=$CI_JOB_TOKEN"'
- ls -la artifacts.zip
- unzip -p artifacts.zip | cat -
Screenshots
Before or FF is off | After and FF is ON |
---|---|
![]() ![]() |
![]() ![]() |