3
votes

GitLab offers to manage a Kubernetes cluster, which includes (e.g.) creating the namespace, adding some tokens, etc. In GitLab CI jobs, one can directly use the $KUBECONFIG variable for contacting the cluster and e.g. creating deployments using helm. This works like a charm, as long as the GitLab project is public and therefore Docker images hosted by the GitLab project's image registry are publicly accessible.

However, when working with private projects, Kubernetes of course needs an ImagePullSecret to authenticate the GitLab's image registry to retreive the image. As far as I can see, GitLab does not automatically provide an ImagePullSecret for repository access.

Therefore, my question is: What is the best way to access the image repository of private GitLab repositories in a Kubernetes deployment in a GitLab managed deployment environment?

In my opinion, these are the possibilities and why they are not eligible/optimal:

  • Permanent ImagePullSecret provided by GitLab: When doing a deployment on a GitLab managed Kubernetes cluster, GitLab provides a list of variables to the deployment script (e.g. Helm Chart or kubectl apply -f manifest.yml). As far as I can (not) see, there is a lot of stuff like ServiceAccounts and tokens etc., but no ImagePullSecret - and also no configuration option for enabling ImagePullSecret creation.
  • Using $CI_JOB_TOKEN: When working with GitLab CI/CD, GitLab provides a variable named $CI_JOB_TOKEN which can be used for uploading Docker images to the registry during job execution. This token expires after the job is done. It could be combined with helm install --wait, but when a rescheduling takes place to a new node which does not have the image yet, the token is expired and the node is not able to download the image anymore. Therefore, this only works right in the moment of deploying the app.
  • Creating an ImagePullSecret manually and add it to the Deployment or the default ServiceAccount: *This is a manual step, has to be repeated for each individual project and just sucks - we're trying to automate things/GitLab managed Kubernetes clusters is designed for avoiding any manual step.`
  • Something else but I don't know about it.

So, am I wrong in one of these points? Am I missing a eligible option in this listing?

Again: It's all about a seamless integration with the "Managed Cluster" features of GitLab. I know how to add tokens from GitLab as ImagePullSecrets in Kubernetes, but I want to know how to automate this with the Managed Cluster feature.

2
It's a known issue, and the answer to your question (IME) is your 3rd bullet point, since CI_JOB_TOKEN expires after the job runs, meaning any Pod that has to be recreated will fail with ImagePullBackOff if scheduled on a different Nodemdaniel
You're right, no automaton in this field so far, very inconvenient to use manual ImagePullSecret.Ihor Kolodyuk

2 Answers

2
votes

There is another way. You can bake the ImagePullSecret in your container runtime configuration. Docker, containerd or CRI-O (Whatever you are using)

Docker

  • As root run docker login <your-private-registry-url>. Then a file /root/.docker/config.json should be created/updated. Stick that in all your Kubernetes node and make sure your kubelet runs as root (which typically does). Some background info.

    The content of the file should look something like this:

    {
          "auths": {
              "my-private-registry": {
                  "auth": "xxxxxx"
              }
          },
          "HttpHeaders": {
              "User-Agent": "Docker-Client/18.09.2 (Linux)"
          }
    }
    

Containerd

  • Configure your containerd.toml file with something like this:
    [plugins.cri.registry.auths]
      [plugins.cri.registry.auths."https://gcr.io"]
        username = ""
        password = ""
        auth = ""
        identitytoken = ""
    

CRI-O

  • Specify the global_auth_file option in your crio.conf file.

✌️

-1
votes

Configure your account.

For example, for kubernetes pull image gitlab.com, use the address registry.gitlab.com:

kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>