Using deploy token to pull from internal registries

Infrastructure as Code & Cloud Native
, ,
1

On my managed GL CE instance I have several projects in a group which serve me as a shared images library. The idea is to have them all in one place to use.

All jobs, that are building images for specific projects are able to use those images thanks to CI_JOB_TOKEN, which we all know and love. So It’s easy to have FROM internal/image added as the base image.

However, there are times, when I want my internal images used directly in my kubernetes cluster. If you deployed at least once to the k8s cluster, you know, that the best pattern is to use gitlab-deploy-token saved in K8S Docker Secret so that there is no issue with image pulling.

Here’s the conflicting problem:
gitlab-deploy-token created in a project does not give me the ability to pull images from internal registries. On the other hand, CI_JOB_TOKEN is short living (by design).

Is there any long-living token, that gives read rights on the private project and all internal projects? I know, I can create a deploy token for my images and publish it on the entire instance, but I’d love to have it all in a single imagePullSecret.

The page which describes different tokens seems to suggest that the deploy token is not scoped to a single project registry, but my manual tests suggest otherwise: GitLab Token overview | GitLab

2

I know this discussion is a bit old now, but I am running into the same issue.

I wish i was able to use my project’s gitlab-deploy-token for image pull secrets and have it also be able to access the registries of all internal projects, but alas, it does not work.

Potential solutions.

  1. use a project access token, which is long lived AND is able to access all internal project registries BUT it looks like soon (16.0) these tokens will have a mandatory expiry and that would randomly break the image pull secret at some future data, which would force me to redeploy apps on a scheduled basis. That has the potential to get messy (eg need to make sure the scheduled job is always going against the latest tag or risk accidentally rolling back the app)
  2. set up multiple deploy secrets as image pull secrets (one per repository from where images need to be pulled) BUT this means i have to manage and copy/paste umpteen secrets to umpteen projects’ CI variables