SSL keystore/truststore dirs and configuration values

[rnpridgeon]

We should manage most of the SSL configuration and directories within the base image. This makes life easier in the long run.

ENV:
-ssl.keystore.location
-ssl.keystore.password
-ssl.key.password

-ssl.truststore.location
-ssl.truststore.password

BASH:
mkdir -p /ssl/keys /ssl/trusts

My understanding is that each containers has it's own layer isolating it from other containers. If this is correct each will still have their own keystore/truststore so key conflicts should not arise.

[rnpridgeon]

We should actually build a base jinja template which includes all shared configuration values such as ZOOKEEPER_CONNECT. Then each service can simply extend this speeding up initial setup of a service within the docker repo.

[arrawatia]

In general, it is not recommended to use ENV vars for secrets in docker. There is lot of discussion on the issue of managing secrets in docker. I have summarized it below

TL;DR

Passing secrets in env vars is bad. The best way for making secrets available to the container is using volumes (Kubernetes does it this way). The basic idea is that you create a mount point for secrets, something like /etc/secrets and the provisioning system puts the secrets in a volume and maps it to the docker container. So, if you are doing it manually for Kafka, you would create a directory on the host, add JKS file and credentials (in a file) and map this directory to /etc/secrets. The configure script will read this dir and add the credentials to the config.

There are various ways of storing secrets and mounting them on a volume for the container, some of which are linked in "Secret management in Docker" section below.

Why ENV vars are bad for runtime secrets ?

• http://elasticcompute.io/2016/01/21/runtime-secrets-with-docker-containers/
• http://movingfast.io/articles/environment-variables-considered-harmful/
• https://superuser.com/questions/708355/is-it-safe-to-store-critical-passwords-in-server-environment-variables

General discussion on "Secrets in docker"

• Secrets: write-up best practices, do's and don'ts, roadmap
• Managing secrets in compose
• Proposal: The Docker Vault
• Does Swarm support the sharing of "secrets"? E.g. encrypted files with passwords in them.
• How to manage secrets in a Microservice / Container / Cloud environment?

Secret management in Kubernetes:

• http://kubernetes.io/docs/user-guide/secrets/

Secret management in Docker

• Keywhiz + docker volume plugin (conceptually same as Kubernetes design):
  • https://square.github.io/keywhiz/
  • https://github.com/calavera/docker-volume-keywhiz
• Using Hashicorp Vault (the docker community seems to like this):
  • https://gist.github.com/voxxit/dd6f95398c1bdc9f1038
  • Real world examples for docker hashicorp/vault#165
  • https://github.com/dockito/vault
• Using Hashicorp Vault (using secrets volume similar to Kubernetes):
  • https://github.com/ehazlett/docker-volume-libsecret
  • https://github.com/ehazlett/libsecret
• Using S3 to manage secrets (by Codahale):
  • https://github.com/codahale/sneaker

[arrawatia]

@theduderog what's your take on this ?

[theduderog]

I agreed that ENV vars are not a good way to pass secrets to containers b/c they're easy to leak. It seems like managing secrets in Docker is similar to "service discovery" in that there is no standard way to do it. Perhaps our default could be to expect a volume to be mounted with the secrets present but we need to allow people to plugin arbitrary code to get their secrets. I guess they can do it by overriding the "configure" step?

[rnpridgeon]

Makes sense to me

[arrawatia]

Implemented in #11.