`DOCKER_AUTH_CONFIG` takes precedence over `docker login`

Xem xét PR #6008 và đường dẫn xác thực của Docker CLI liên quan đến DOCKER_AUTH_CONFIG, docker login và docker push. Tái hiện chuỗi GitLab CI với thông tin xác thực chỉ đọc và ghi, sau đó xác minh rằng hành vi thu được khớp với thứ tự ưu tiên thông tin xác thực dự kiến hoặc báo cáo rõ ràng thông tin xác thực nào đang được sử dụng.

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

1. Use docker:dind in GitLab CI.
2. Set DOCKER_AUTH_CONFIG with read-only credentials to access a private registry.
3. Run docker login private-registry.xxx.com with credentials that have write access.
4. 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