`docker login` does not respect `docker context`

[nicks]

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:

1. Install docker engine and docker-desktop on linux
2. Turn off docker-desktop
3. Change your context to docker engine
4. 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

[patrick-petrovic]

@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.

[nicks]

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.