Store client certificates in config.json

[hobti01]

Description
As a user, it would enhance the user experience if all repository credential and connection information were stored within ~/.docker/config.json. Currently username/password or token are stored within the config.json file. I propose that CA certificate (ca.crt), client.cert, and client.key are also stored in this file, replacing the current storage mechanism in /etc/docker/certs.d/{registry}/ on each host.

{
  "auths": {
    "my-https-registry.example.com": {
      "auth": "YWJjOjEyMw==",
      "tls": {
        "ca.crt": "base64encoded.ca.crt",
        "client.cert": "base64encoded.client.cert",
        "client.key": "base64encoded.client.key"
      }
    }
  }
}

Storing the client certificates within the configuration file would enhance the usability with Mesos, Kubernetes, OpenShift, Docker Swarm, and others. The alternative which requires installation of the certificates on each docker daemon separates two parts of the registry credentials between different responsibilities.

• docker swarm join does not mention client certificates
• docker service create --with-registry-auth also does not mention or handle client certificates

The security implications of storing private keys (and passwords) within a file on each host should not be ignored. config.json should not be stored as an unprotected file and should be directly provided to the docker daemon.

Related issues
This is similar to #30591 which is requesting that certs for the docker daemon be stored in .docker/config.json
This is related to docker/for-mac#1320 which outlines how the host access requirement to inject client certificates is not practical with the Docker for Mac approach. The same limitation may exist on Docker for Windows.

[cpuguy83]

/etc/docker/certs.d is for storing CA's to trust some registry rather than running without verifying the registry certs... it's also probably better to use the system certificate pool rather than this dir.

I do not think we want to store actual certificates in this file, and also these certificates are not used to talk to a registry in any case (unless there's some feature somewhere I don't know about, which is possible!).
Even storing the passwords in this file is bad practice and we push people towards using https://github.com/docker/docker-credential-helpers... also note docker4mac as of today uses the credential helper instead of storing the password in (essentially) plain text in the config.json.

[hobti01]

@cpuguy83 Am I misunderstanding the user guide that specifies putting client.cert and client.key within /etc/docker/certs.d? I'm specifically not talking about the server certificate, but the client certificate that must be used by the docker daemon for TLS communication with a registry that requires client certificate verification.

The presence of one or more <filename>.key/cert pairs indicates to Docker that there are custom certificates required for access to the desired repository.

It looks like the credential store/helper is a much better solution, but lightly documented - I seem to only locate a small mention with the docker login CLI reference without a link to documentation for the helpers, is there a more comprehensive guide?

Could you help me understand how a client.cert and client.key are used with the credential helper? It doesn't look like the Credential structure accommodates certificates.

[thaJeztah]

I'd prefer to keep the certificates out of the config.json as well. I know discussing keeping "sensitive" data and "customization" data separate (just added it as a comment on #30025 (comment))

[matthewbarr]

As much as I'd love to be able to use a single file, Credentials would help: Being able to store client certs at least encrypted would be excellent. That's a good start to actually using say the Keychain on the Mac, or something.

[taemon1337]

I think the real issue here is that on Kubernetes for example, a user can provide a docker registry ImagePullSecret using username/password that is tied to a service account but cannot provide using TLS certificate. A user of Kubernetes is often unlikely able to inject tls certificates onto each node at /etc/docker/certs.d/{domain}/client.crt but can provide a username/password in the image pull secret to pull from a private registry. The ability to dynamically specify a client tls cert/key to use or config.json would enable this ability. This issue seems to be partly a Kubernetes issue as well

(see kubernetes/kubernetes#41965 and kubernetes/kubernetes#91413)

[kmeekva]

I agree with @taemon1337. Seems there is no way for Kubernetes to be able to provide the client certificates necessary to pull images from a private registry requiring client certs.