GitLab CI Kubernetes Runner does not honor DOCKER_AUTH_CONFIG
Summary
GitLab CI Kubernetes Runner does not honor Docker authorization configuration for private registries in DOCKER_AUTH_CONFIG.
It seems that setupCredentials function in Kubernetes executor uses only authentication credentials from the job payload.
Steps to reproduce
- Set up GitLab Runner to use a Kubernetes cluster.
- Pick any image in a private Docker registry which is NOT accessible implicitly from the Kubernetes cluster (for example, don't use gcr.io when running Kubernetes on Google Cloud, or azurecr.io when running on Azure).
- Try to run a job using that image while passing an appropriate
DOCKER_AUTH_CONFIGenvironment variable.
Actual behavior
Image pull fails when starting the job pod.
Expected behavior
Image pull should succeed.
Relevant logs and/or screenshots
Running with gitlab-ci-multi-runner 9.4.1 (d24b11c)
on Kubernetes Runner (6066fd46)
Using Kubernetes namespace: gitlab-ci
Using Kubernetes executor with image $BUILDENV_IMAGE:$BUILDENV_KEY ...
Waiting for pod gitlab-ci/runner-6066fd46-project-29-concurrent-0s2qc6 to be running, status is Pending
Waiting for pod gitlab-ci/runner-6066fd46-project-29-concurrent-0s2qc6 to be running, status is Pending
Waiting for pod gitlab-ci/runner-6066fd46-project-29-concurrent-0s2qc6 to be running, status is Pending
ERROR: Job failed: image pull failed: Back-off pulling image "<snipped>"Environment description
This is a on-premise installation of GitLab. GitLab Runner is deployed into a Kubernetes cluster on Azure. The image is not from an Azure Container Registry, which is available without any manual authentication in this cluster.
Proposal
- At the moment all the logic around authentication is inside of the Docker executor. Extract the authentication into a common library just like what we tried in !1164 (diffs) keep in mind !1164 (comment 161663797). This should be a package under https://gitlab.com/gitlab-org/gitlab-runner/-/tree/master/helpers/docker maybe it's own package
authwhich will be responsible of all the authentication. - When there is a common library that we can have both the Docker and Kubernetes executor use it.