Version 3.1 of the docker-compose.yml specification introduces support for secrets.
I tried this:
version: '3.1'
services:
a:
image: tutum/hello-world
secret:
password: the_password
b:
image: tutum/hello-world
$ docker-compose up
returns:
Unsupported config option for services.secret: 'password'
How can we use the secrets feature in practice?
Given you have a service
myapp
and a secrets filesecrets.yml
:Create a compose file:
Provision a secret using this command:
Deploy your service using this command:
Now your app can access the secret file at
/run/secrets/secrets_yaml
. You can either hardcode this path in your application or create a symbolic link.The different question
This answer is probably to the question "how do you provision your secrets to your docker swarm cluster".
The original question "how do you manage secret values with docker compose" implies that the docker-compose file contains secret values. It doesn't.
There's a different question: "Where do you store the canonical source of the
secrets.yml
file". This is up to you. You can store it in your head, print on a sheet of paper, use a password manager, use a dedicated secrets application/database. Heck, you can even use a git repository if it's safely secured itself. Of course, never store it inside the system you're securing with it :)I would recommend vault. To store a secret:
To retrieve a secret and put it into your docker swarm:
Of course, you can use docker cluster itself as a single source of truth for you secrets, but if your docker cluster breaks, you'd lost your secrets. So make sure to have a backup elsewhere.
The question nobody asked
The third question (that nobody asked) is how to provision secrets to developers' machines. It might be needed when there's an external service which is impossible to mock locally or a large database which is impossible to copy.
Again, docker has nothing to do with it (yet). It doesn't have access control lists which specify which developers have access to which secrets. Nor does it have any authentication mechanism.
The ideal solution appears to be this:
docker secret create
commands and executes them in the terminal.We have yet to see if such an application pops up.
I guess the keyword is
secrets
notsecret
. That is at least what I understand from reading the schema.You can also specify
secrets
stored locally in a file usingfile:
key insecrets
object. Then you don't have todocker secret create
them yourself, Compose /docker stack deploy
will do it for you.Reference: Compose file version 3 reference: Secrets
Is that the exact indentation of your
docker-compose.yml
file? I thinksecret
secrets
should be nested undera
(i.e. one of the services), not directly underservices
section.You can read the corresponding section from the official documentation.
To use secrets you need to add two things into your
docker-compose.yml
file. First, a top-levelsecrets:
block that defines all of the secrets. Then, anothersecrets:
block under each service that specifies which secrets the service should receive.As an example, create the two types of secrets that Docker will understand: external secrets and file secrets.
1. Create an 'external' secret using
docker secret create
First thing: to use secrets with Docker, the node you are on must be part of a swarm.
Next, create an 'external' secret:
(Make sure to include the final dash,
-
. It's easy to miss.)2. Write another secret into a file
3. Create a
docker-compose.yml
file that uses both secretsNow that both types of secrets are created, here is the
docker-compose.yml
file that will read both of those and write them to theweb
service:Docker can read secrets either from its own database (e.g. secrets made with
docker secret create
) or from a file. The above shows both examples.4. Deploy your test stack
Deploy the stack using:
This will create one instance of the
web
service, namedsecret_test_web
.5. Verify that the container created by the service has both secrets
Use
docker exec -ti [container] /bin/sh
to verify that the secrets exist.(Note: in the below
docker exec
command, them2jgac...
portion will be different on your machine. Rundocker ps
to find your container name.)If all is well, the two secrets we created in steps 1 and 2 should be inside the
web
container that was created when we deployed our stack.