Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve usability for TLS usage and setup #6817

Open
huslage opened this issue Jul 2, 2014 · 11 comments
Open

Improve usability for TLS usage and setup #6817

huslage opened this issue Jul 2, 2014 · 11 comments

Comments

@huslage
Copy link
Contributor

@huslage huslage commented Jul 2, 2014

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.

@dmp42 dmp42 added the Trust label Jul 2, 2014
@SvenDowideit
Copy link
Contributor

@SvenDowideit SvenDowideit commented Jul 21, 2014

@discordianfish @huslage does this need to be ubuntu? or can you re-do using a minimal debian:jessie (or even smaller) ?

@discordianfish
Copy link
Contributor

@discordianfish discordianfish commented Jul 21, 2014

@SvenDowideit Why not just try it?

@SvenDowideit
Copy link
Contributor

@SvenDowideit SvenDowideit commented Jul 21, 2014

I ask in case you guys already know a reason - ie, to make sure I'm not replicating a known waste of time :) or in case someone has succeeded somewhere else (like with busybox)

@david-guenault
Copy link

@david-guenault david-guenault commented Mar 3, 2015

Well i'm also facing this problem. What i do is using a Makefile that deal with all the certificates management.

  • root CA
  • signing CA
  • client/server certs
  • client certs
  • certificate revocation with crl (and publish endpoints)

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

@samrocketman
Copy link

@samrocketman samrocketman commented Jan 27, 2016

It would be nice if CRL at the very least was supported. I don't feel OCSP really applies here because it's typical the certificate authority is internal.

@md-5
Copy link

@md-5 md-5 commented Feb 19, 2016

Without recovation, how is the current TLS implementation any better than static keys?

@samrocketman
Copy link

@samrocketman samrocketman commented Mar 4, 2016

FYI, I think supporting a set of scripts would be easy to do. I wrote up repeatable scripts that I could probably open source with permission from my company.

@mgenov
Copy link

@mgenov mgenov commented Jul 6, 2017

Related with #27778

@standagh
Copy link

@standagh standagh commented Dec 5, 2017

Also voting for CRL, OCSP and SCVP.
And have a question - in case corporate CA is used it would be nice to provide mechanism how to narrow down list of certs signed by corporate CA and allowed to connect to docker? What mechanism should be used? I don't like the idea of using swarm-local CA.
For example IBM uses SSLEER mechanism for it's messaging product https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.ref.con.doc/q082250_.htm ;)

@DanielFallon
Copy link

@DanielFallon DanielFallon commented Mar 9, 2018

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

@samrocketman
Copy link

@samrocketman samrocketman commented Mar 10, 2018

I've updated my personal CA to handle client certificates. This allows certificate management via an easy set of scripts. https://github.com/samrocketman/my_internal_ca

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet