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::Scopeinbound_accessible?method, a condition `group_accessible?(accessed_project) behind a feature flag - Implement
group_accessiblewith the scope validation by matchingcurrent_groupofcurrent_project, withtarget_groupiterated fromCi::JobToken::GroupScopeLinkof 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.rbandapp/models/ci/job_token/allowlist.rbgroups 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_projecton theprivate_source_group - Create a
private_target_group - Create a
private_target_projectin theprivate_target_group - Generate an artifact on
private_source_projectby 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_projectwith.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 |
|---|---|
|
|



