Secret Properties for containers

[usmanismail]

I need a good way of getting a secret into a docker container running on top of Rancher. The best so far is to use environment variables at creation time but these can be seen from the API.

I could volume mount files as well but those need to be pre-created into the underlying host.

Any ideas?

[thaJeztah]

There's a proposal in docker for "vaults"; moby/moby#10310 So far it didn't get much "traction" but you might be interested. It will still require the vaults to be created before deploying a container though.

[hibooboo2]

@usmanismail What type of secret files or just things like ssh keys and environment variables?

[usmanismail]

In our specific case Amazon AWS Credentials. So either of env variable or files works as amazon supports both kinds of authentication.
Files are better than env variables in general

[ibuildthecloud]

This is on the roadmap but it's being bundled into the "phase 2" of docker compose support. The basic idea is this. With our compose support we take a compose yml but then have an additional rancher.yml file. The rancher yaml is for rancher specific settings and also environment specific settings. For example, in your compose you might have a service that is "mysql". So when you do a "compose up" it creates a container with mysql in it. That works for local dev, but once you push to production MySQL might be RDS on Amazon. So in the rancher.yml you can override things and say something like "in production really use IP 1.1.1.1 for mysql".

In that rancher.yml we will provide the ability to put encrypted values. Rancher will generate a public/private encryption key, but the private key will never be shared. You can just use the public key to encrypt. (This is very similar to travis-ci). Once you have the encrypted values in the rancher.yml you can then specify which containers should have access to that secret value. At deployment time we will then decrypt the value and place it on disk in a specific location.

There are still quite a few details to work about, but that is the high level idea. Based on the Docker Vault PR and a previous secrets PR, it seems the general direction is that secrets will be placed in files for the container to use. We intend to follow the same approach hoping that it will be close to compatible with what Docker will eventually do themselves.

[thaJeztah]

Sounds good, @ibuildthecloud. FYI there's a proposal to split the docker-compose.yml into a "definition" and "config" file here docker/compose#846. That approach seems so match (roughly) to what you're describing here, which would be nice. (Compose itself won't support encryption though, so that's a difference).

Maybe @aanand has some new insight if there are new developments there; would be nice indeed if the implementations matched closely.

[will-chan]

Tracking using #1269 instead.