`docker login` does not respect `docker context`
Description
If you have two different docker contexts with different credential systems, docker login does not interact with them correctly
Steps to reproduce the issue:
- Install docker engine and docker-desktop on linux
- Turn off docker-desktop
- Change your context to docker engine
- Type
docker login
Describe the results you received:
nick@dopey:~/src/ctlptl$ docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com/ to create one.
Username: nicksantos624
Password:
Error saving credentials: error storing credentials - err: exit status 1, out: `Post "http://ipc/registry/credstore-updated": dial unix /home/nick/.docker/desktop/backend.sock: connect: connection refused`
nick@dopey:~/src/ctlptl$ docker context list
NAME TYPE DESCRIPTION DOCKER ENDPOINT KUBERNETES ENDPOINT ORCHESTRATOR
default * moby Current DOCKER_HOST based configuration unix:///var/run/docker.sock https://127.0.0.1:34777/ (default) swarm
desktop-linux moby unix:///home/nick/.docker/desktop/docker.sock
Describe the results you expected:
Use the engine for authentication
Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version:
Client: Docker Engine - Community
Cloud integration: v1.0.25
Version: 20.10.17
API version: 1.41
Go version: go1.17.11
Git commit: 100c701
Built: Mon Jun 6 23:02:57 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.17
API version: 1.41 (minimum version 1.12)
Go version: go1.17.11
Git commit: a89b842
Built: Mon Jun 6 23:01:03 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.6
GitCommit: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
runc:
Version: 1.1.2
GitCommit: v1.1.2-0-ga916309
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Output of docker info:
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Docker Buildx (Docker Inc., v0.8.0-115-g6cb026b7.m)
compose: Docker Compose (Docker Inc., v2.6.0)
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
scan: Docker Scan (Docker Inc., v0.17.0)
Server:
Containers: 43
Running: 3
Paused: 0
Stopped: 40
Images: 168
Server Version: 20.10.17
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
runc version: v1.1.2-0-ga916309
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: default
cgroupns
Kernel Version: 5.15.0-37-generic
Operating System: Ubuntu 22.04 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.31GiB
Name: dopey
ID: 7YPJ:74MM:WUZR:32Z5:MAZN:PR44:65VV:3MME:5Y2J:SFFB:42KM:X27F
Docker Root Dir: /var/lib/docker
Debug Mode: false
Username: nicksantos624
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
71.105.118.205:38335
registry.local:5000
0.0.0.0:41315
127.0.0.0/8
Live Restore Enabled: false
@nicks it looks like the CLI always uses the same credential store as configured in ~/.docker/config.json. The secret store can be any kind of store (e.g., macOS Keychain). Docker Desktop just happens to provide its own secret store (desktop).
I doubt that the default credential store should be changed, since this setting likely makes sense for most users. However, I can imagine it would be helpful to have an optional --credsStore flag that overrides the value in config.json for a specific context. This approach would give users the option to have multiple secret stores while preserving backwards compatibility.
Another possibility is that docker desktop credential helper should fallback gracefully if docker desktop is not running...it's not 100% clear to me why it can't fallback to the OS cred store, then load the creds when it starts.