Skip to content

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.

  1. Inject to Ci::JobToken::Scope inbound_accessible? method, a condition `group_accessible?(accessed_project) behind a feature flag
  2. Implement group_accessible with the scope validation by matching current_group of current_project, with target_group iterated from Ci::JobToken::GroupScopeLink of the accessible project allow list, more details
  3. 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

  1. Database design of group list table and model - job_token/group_scope_link - (MR: !142749 (merged))
  2. Add into app/models/ci/job_token/group_scope_link.rb and app/models/ci/job_token/allowlist.rb groups validation together with inbound lists, behind a feature flag group_scope_link_allowlist 👈 you are here
  3. GraphQL implementation (MR: !143132 (merged))
  4. 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

  1. Enable a FF: ::Feature.enable(:ci_job_token_groups_allowlist)
  2. Create for example private_source_project on the private_source_group
  3. Create a private_target_group
  4. Create a private_target_project in the private_target_group
  5. Generate an artifact on private_source_project by creating .gitlab-ci.yml
create_artifact:
  script:
    - echo "artifacts data" > artifact.txt
  artifacts:
    paths:
      - artifact.txt
  1. Add manually a group into groups allowlist:
  Ci::JobToken::GroupScopeLink.create(source_project: private_source_project, target_group: private_target_group, added_by: user)
  1. 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
image image image image
Edited by Dmytro Biryukov

Merge request reports

Loading