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

Comments

Projects
None yet
@huslage
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Jul 21, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@discordianfish

discordianfish Jul 21, 2014

Contributor

@SvenDowideit Why not just try it?

Contributor

discordianfish commented Jul 21, 2014

@SvenDowideit Why not just try it?

@SvenDowideit

This comment has been minimized.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Jul 21, 2014

Contributor

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)

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@david-guenault

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

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

@icecrime icecrime removed the dist/trust label Jul 17, 2015

@samrocketman

This comment has been minimized.

Show comment
Hide comment
@samrocketman

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

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

This comment has been minimized.

Show comment
Hide comment
@md-5

md-5 Feb 19, 2016

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

md-5 commented Feb 19, 2016

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

@samrocketman

This comment has been minimized.

Show comment
Hide comment
@samrocketman

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

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

This comment has been minimized.

Show comment
Hide comment
@mgenov

mgenov Jul 6, 2017

Related with #27778

mgenov commented Jul 6, 2017

Related with #27778

@standagh

This comment has been minimized.

Show comment
Hide comment
@standagh

standagh 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 ;)

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

This comment has been minimized.

Show comment
Hide comment
@DanielFallon

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

@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

This comment has been minimized.

Show comment
Hide comment
@samrocketman

samrocketman 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

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