Skip to content

create ci-extended-job-token in the ci-job-info

Description

The ci-job-token is actually a very nice alternative authorisation for the gitlab-api, registry and repository usage from within a ci-job without having to define yet another personal token.

Especially since 8.12, with a beautiful concept where the ci-job-token represents the user who triggers the pipeline. But due to security concerns in shell-executors, privileged docker containers and ssh executors , the scope of access has been drastically limited as the token could be obtained and abused by non authorised people in these unsafe executors.

Nevertheless, it would be opportune to have a way to extend the scope of the token, as noticed by the presence of several issues regarding the scope for:

  1. Gitlab-API access on non public projects, for the project and across projects the user has access to.(private project submodules)
  2. Repository access to non public projects outside the project which has the build job and the user has access to. (also push)
  3. Registry access to non public registries across projects the user has access to.
  4. runner to use a build-image from a private gitlab-registry to build the project without having to login into the build server and leave your personal credentials behind!!!
  5. PUSH RELEASE URLS with GitLab 11.7!!!

these things are today not possible due to the restricted scope of the ci-job-token with no advance nor target dates/milestones.

Proposal

Add an ci-extended-job-token, similar as our ci-job-token, with the same rights as the user without extra scope restrictions, to the job-info, but NOT within the job-info:variables of the JSON result of the GET JOB API.

By not placing this token in the job-info:variables we can prevent this token to become availleble as an environment variable for older runners,

yet a new runner could make this ci-extended-job-token availleble in the variables or even replace the ci-job-token, if the job executor is safe!

This would allow, in a safe way, to access private projects API, registry and repositories, as the user who initiate the pipeline and with the same access as that user from within a CI-job.

Secondly have runner to use the extended-job-token for:

  1. for repository pulls( and sub modules)
  2. for pulling build-images from non public projects (docker login with the ci-extended-job-token)

Related issue's dealing with access for JOB_TOKEN from within CI

Don't know if already issue, but writing Release urls on Release from CI would also be mandatory!

of which most are lingering around for months / years and could be solved with this feature request!!!!

Or some have been closed (e.g. use non public build image by creating a docker login and leave personal token or login behind on a docker build server !!)

@markglenfletcher @bikebilly @ayufan anybody we should add in cc who can get this feature a boost?

Edited by Danny