We have a set of services where one of the containers makes docker client calls back to the docker engine to do various things (start a short-lived container, do some management, whatever)
This works fine unless we have TLS enabled on the docker engine instance.
From the container, it looks easy to generate a client key when the container starts up (though I really don’t want to have to install openssl on this container…). But it looks like the server side key needs to have the IP addresses of the clients in advance it is created.
This is a bit of a chicken-egg problem because we won’t know the IP of the container until it starts.
Is there a way around this? Perhaps a second docker-engine port that only listens on the internal docker network?
It is the other way around, you just have to copy the client keys into the client container. The clients need the client keys and the engine IP address.
--tlscacert=$DOCKER_CERT_PATH/ca.pem Trust certs signed only by this CA
--tlscert=$DOCKER_CERT_PATH/cert.pem Path to TLS certificate file
--tlskey=$DOCKER_CERT_PATH/key.pem Path to TLS key file
So cert.pem (client cert public key), key.pem (client cert private key) and ca.pem (CA public key).
From the docs:
If found, the client will send its client certificate, so you just need to drop your keys into ~/.docker/{ca,cert,key}.pem. Alternatively, if you want to store your keys in another location, you can specify that location using the environment variable DOCKER_CERT_PATH.
Thanks for your help! You’re right, it is the other way around.
And if a docker container wishes to connect via the internal IP address of the docker engine host (e.g. 172.17.0.1), that has to be added as an “alt SAN” to the server key. Looks like docker-machine has that functionality:
I also found that just mounting a directory with the pem files (if they exist) works, too. This is a little better for us because not all our environments have TLS enabled.