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:
- Gitlab-API access on non public projects, for the project and across projects the user has access to.(private project submodules)
- Repository access to non public projects outside the project which has the build job and the user has access to. (also push)
- Registry access to non public registries across projects the user has access to.
- 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!!!
- 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:
- for repository pulls( and sub modules)
- for pulling build-images from non public projects (docker login with the ci-extended-job-token)
JOB_TOKEN
from within CI
Related issue's dealing with access for - #17511 : 139 Up-votes : Allow API project access with ci_job_token for internal project or public project with member only access to repository or private project
- gitlab-foss#40096 (closed) : 30 Up-votes : Delete image tag registry
- gitlab-foss#39641 (closed) : 1 Up-votes
- #19937 (closed) : 26 Up-votes (Cannot clone git repo using GitLab CI runners token)
- #18284 : 5 Up-votes (Docker push to different repo leads to denied: requested access to the resource is denied)
- #19488 (closed) : 3 Up-votes (Docker Container Registry access forbidden)
- #16008 (closed) : 1 Up-votes (Docker registry access to protected package)
- #14101 (closed) : 315 Up-votes (Feature Request: Allow runners to push via their CI token)
- #19682 (closed) : 4 upvotes (Should we allow a runner to generate temporary personal access token in order to push in GitLab API projects ?)
- #23067 (closed) : 10 Up-votes (write_repository scope to Deploy Tokens)
- #9104 (closed) : 15 Up-votes Authenticate with CI_JOB_TOKEN to NPM registry
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?