I want to pass a secret value needed by an app that runs in a Docker container. This particular container is short-lived -- it starts up, runs a command, and then terminates.

Method 1: Pass the value as an environment variable via the command line when starting the container (Docker supports this as a command line argument to starting a container). I feel like this is bad since the command will show up in process lists (with the key and all) on the host machine that started the docker container.

Method 2: Pass the value as an env variable via an env variable file. This solves the process list issue, but running docker info on the running container from the host shows a list of all the environment variables set for that container. This makes me believe Docker is storing these somewhere on disk on the host that is unsafe (since adding a new environment variable in the running container does not update this list, it must not be reading it directly in real-time).

In general, I feel like environment variables are not adequate to securely store secret data (even if only temporarily), but I do not have enough knowledge to back up this thought.

What is a secure method for passing secret data to a container?

  • Which operating system is this for? – LateralFractal Oct 16 '14 at 2:28
  • is the secret data consistent or different for each container? what exactly is the secret used for? – theterribletrivium Oct 16 '14 at 9:32
  • @LateralFractal CentOS 7 – Anthony Kraft Oct 16 '14 at 20:17
  • @theterribletrivium the secret data is consistent in this exact case (but some may not be). It is used to pass in a password for a first time initialization of a DB user. – Anthony Kraft Oct 16 '14 at 20:18

Environment variables are the best way to do this, specifically method 2. Docker, by default, does not allow itself to be run by users other than root. Access to the socket is prohibited. I'd say method 2 is reasonably safe, as out of the box if an attacker has root access (and can poke around in your docker containers) you're already in bad shape.

Two Docker security notes in general. Be super cautious with enabling the API, as by default there is no encryption or authentication. They have a way to use certs and TLS that they documented, but proceed with caution.

Also, if possible enable SELinux on your server. Newer versions of it are able to actually see docker containers and automatically build security contexts for each one. This prevents a container compromise from easily moving back into the host. By default docker runs as the root user, and even with the USER directive it still interfaces directly with the kernel unlike a VM. This exposes the host to any local privilege exploit as soon as a docker container is compromised.

  • You seem knowledgeable on this topic, so I'll ask: SELinux with containers works best when you can assign an MCS category to the running container, and label the files it needs with that MCS label to prevent other different containers from accessing other containers' files (in the event of a break out). I cannot seem to find a way to set the MCS label on a docker container (it can only be randomly generated), which makes it difficult to deal with when I update the container (i.e. new random label that can't access the files). Do you know if there is a way to handle this? – Anthony Kraft Oct 16 '14 at 20:41
  • 1
    Also, how does this change for more persistent info, like say, an ssl private key? – Anthony Kraft Oct 16 '14 at 21:00
  • Can you go into a little more detail in regards to what files you're accessing? I wouldn't typically expect or want one container to talk to another in general, except in cases involving performance or that sort of thing. To the SSL key, it doesn't change it much. Just guard the material the same way you would otherwise. – theterribletrivium Oct 16 '14 at 22:41
  • The most common scenario I can think of is mounting a DB data volume from the host. If you put out a new db image, I would like to be able to specify the MCS category instead of getting a random one. Interesting, Docker 1.3 was announced a few hours ago and appears to have solved this with the new --security-opt command line arg to the run command – Anthony Kraft Oct 17 '14 at 0:39
  • 1
    @theterribletrivium using environment variables for secrets is officially considered a hack: Features / hacks that are (mis)used for secrets – ArtB Jan 8 '16 at 21:54

Docker guys have recently introduced their native solution for this: https://blog.docker.com/2017/02/docker-secrets-management/

The usage pattern is:

$ echo "This is a secret" | docker secret create my_secret_data -
$ docker service  create --name="redis" --secret="my_secret_data" redis:alpine

The unencrypted secret is then mounted into the container in an in-memory filesystem at /run/secrets/<secret_name>.

Though this is only accessible within a swarm

You can find full documentation here: https://docs.docker.com/engine/swarm/secrets/

  • This is a great update, but please include the relevant parts of the link in your answer. – schroeder Apr 27 '17 at 11:48

docker secret only works in swarm mode. For local mode, to pass some simple secret, such as password, we can read the password into a variable from stdin. The difficulty comes with the detach mode, which will hang while reading the pipe within the container. Here is a trick to work around:

cid=$(docker run -d -i alpine sh -c 'read A; echo "[$A]"; exec some-server')
docker exec -i $cid sh -c 'cat > /proc/1/fd/0' <<< _a_secret_

First, create the docker daemon with -i option, the command read A will hang waiting for the input from /proc/1/fd/0; Then run the second docker command, reading the secret from stdin and redirect to the last hanging process. The secret will only be read once, and will not be inspected.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.