Extend CI_JOB_TOKEN scopes per job

Proposal

The current scopes of the CI_JOB_TOKEN are outlined at https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html, e.g.:

  • read_repository
  • read_registry
  • write_registry and others.

Since several years there are different issues and epics which in end boil down to somehow giving the user who created a job either by pushing, merging or directly triggering a pipeline and the resulting jobs with extended permissions/scopes for the project in contrast to today.

Several workarounds currently in place are usage of personal access tokens or the lateron introduced group a project access tokens. PATs are bound to a single user, so a lot of people started adding technical team/group users which take another seat license. Both PATs as group/project ATs are suffering from the need of regular rotation which is error prone. As of March 2023, the access of the CI_JOB_TOKEN is even further reduced by default for other projects as other projects need to be explicitly configured to allow access.

Proposals in Add new endpoints to fine-grained permissions f... (&6310 - closed) look heavy weight because they want to define additional scopes for tokens in the project (or maybe group) CI/CD settings. This needs both collaboration of UI and backend teams and has the additional disadvantage that is intransparent (not visible to people without at least maintainer rights) and at the same time too general as the extended scopes would be valid for whole pipelines and not single jobs.

This issue proposes to just add another keyword in .gitlab-ci.yml which may be defined either at the job level or in the default section.

job1: ...
job2: ...

release job:
  script:
    - my-release-script
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
      when: manual
    - when: never
  ci_job_token:
    scopes: [write_repository, read_api]

Here all jobs except of the release job would still keep the reduced set of permissions as before and only this job could e.g. create a tag in the project and collect easily commit information via API to determine the next version for a project which uses conventional commit.

Related epics

Both epics collected ideas from even older issues which were consequently closed.

Related issues