`DOCKER_AUTH_CONFIG` takes precedence over `docker login`
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- docker, gitlab, go
- Área
- authentication, ci-cd, cli
Línea de trabajo
Revisa el PR #6008 y el flujo de autenticación de Docker CLI relacionado con DOCKER_AUTH_CONFIG, docker login y docker push. Reproduce la secuencia de GitLab CI con credenciales de solo lectura y de escritura, y verifica después que el comportamiento resultante coincida con la precedencia esperada de las credenciales o indique claramente qué credenciales se están utilizando.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Description
First of all, apologies if this is not the appropriate place to raise this — please feel free to redirect me if this should be handled elsewhere.
Context
Since the merge of PR #6008, we're experiencing issues when pushing to a private registry from a GitLab CI job using the docker:dind image.
Our GitLab CI pipelines pull images from a private registry using a read-only service account. To support this, we initialize the DOCKER_AUTH_CONFIG environment variable with a base64-encoded JSON config containing the read-only credentials (following the principle of least privilege). This is mandatory to allow the GitLab Runner to pull our job image.
Later in the pipeline, we perform a docker login with another service account that has write permissions, in order to push new images. The login correctly updates the ~/.docker/config.json file.
Issue
After the change introduced by this PR #6008, it seems that the DOCKER_AUTH_CONFIG environment variable continues to take precedence, even after a successful docker login. As a result, docker push fails with permission denied errors because it is still using the read-only credentials from DOCKER_AUTH_CONFIG.
Furthermore, there is no message or warning from the Docker CLI indicating that DOCKER_AUTH_CONFIG is being used in preference to the updated login credentials. This makes it especially difficult to diagnose the root cause, as one would expect the docker login command to override or be honored for subsequent operations.
Previously, docker login would override the current auth context, allowing the push to succeed using the updated credentials.
Maybe I misunderstood this change and we could do otherwise? Or maybe this is a bug introduced with this PR. Thanks for your help.
Reproduce
- Use
docker:dindin GitLab CI. - Set
DOCKER_AUTH_CONFIGwith read-only credentials to access a private registry. - Run
docker login private-registry.xxx.comwith credentials that have write access. - Attempt to run
docker push private-registry.xxx.com/repo/image:tag.
unauthorized: unauthorized to access repository: repo/image, action: push: unauthorized to access repository: repo/image, action: push
Expected behavior
docker push should succeed using the credentials updated via docker login.
docker version
Client:
Version: 28.3.0
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.25.0
Path: /usr/local/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.37.3
Path: /usr/local/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 1
Server Version: 28.3.0
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
runc version: v1.2.6-0-ge89a299
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 5.16.14-1.el8.elrepo.x86_64
Operating System: Alpine Linux v3.22 (containerized)
OSType: linux
Architecture: x86_64
CPUs: 32
Total Memory: 125.8GiB
Name: eae77d15590e
ID: 024926f0-57c7-4049-b2a5-c3e33d4dca88
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Additional Info
No response
- Lenguaje dominante
- Go
- Estrellas
- 6.1k
- Forks
- 2.2k
- Merge medio
- 1 d 10 h
- PR fusionados (30 d)
- 47
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de docker/cli
-
kind/bug status/0-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
kind/bug status/0-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
-
kind/feature status/0-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
kind/bug status/0-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Todos los issues de docker/cli
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
acceptance-tests phase-coding schema-coverage testing triaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100