I want to pass a secret value needed by an app that runs in a Docker container.

Question

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?

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.