Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve usability for TLS usage and setup #6817
Right now it is very complicated and problematic for a user to create all of the certificates required to secure Docker.
@discordianfish wrote a Dockerfile to show the entire process: https://gist.github.com/discordianfish/1d2bbc5bf2d94fee147b
It turns out that repeatability is a big deal. If I make certs on my mac and import them into boot2docker, for instance, there are "Bad Certificate" errors on the client side.
We need to provide built-in tooling for generating keys for basic security out-of-the-box, while still allowing users the flexibility to generate their own keys.
Well i'm also facing this problem. What i do is using a Makefile that deal with all the certificates management.
I do not think a complete tooling is needed since organizations already manage this process (internal or external). But we need a better documentation and support for the various revocation implementations such as CRL, OCSP and SCVP. At the moment i do not think any of those implementations are supported in docker (even CRL and OCSP that are already suported in golang net/http).
referenced this issue
Mar 16, 2017
Also voting for CRL, OCSP and SCVP.
@standagh I think the typical thought with regards to using swarm-local CA is that another way of limiting the scope of damage in the event of a breach is to limit the scope of systems that trust a CA.
If your provisioning process for new docker nodes gets compromised, or the process of issuing new certs for those on the infrastructure team were to be compromised, would you want that to impact just a single cluster, or the entire company? Potentially you could revoke the certificates, but this limits exposure and minimizes the CAs value.
There are ways to limit this such as x509 name constraints but support by client applications is not particularly widespread, so until name constraints becomes more prevalent, it's best to limit the scope of trust for any corporate CA when possible.