48

I have a base docker image which is used to run image analysis software. For each container created from the image, there are a set of configuration settings, some of which are secrets (encryption keys, customer information, etc.), that are used by the software to analyze and distribute the processed images. How can I safely pass these secrets to a container?

Improve this question
1
  • Hashicorp vault
    – 030
    Apr 18, 2018 at 14:38

2 Answers 2

Reset to default
41

You have 3 methods to get secrets to an app inside a docker container. The first 2 involve docker configuration. The last one is to have your apps directly fetch secrets from a secret store.

1 - Environment variables

According to "The 12 Factor App" guide, secrets are merely config, and they should always be set in the environment. You could set your secrets as environment variables during the docker run, and your app accesses them from there.

2 - Mounted volumes

You could have your secrets all within a particular configuration/secrets file, then mount that to your instance as a mounted volume.

3 - Fetch from secret store

As @030 mentioned, you can use Hashicorp Vault (or "Amazon Secrets Manager", or any service like that).
Your app, or a sidecar app can fetch the secrets it needs directly, without having to deal with any configuration on the Docker container. This method would allow you to use Dynamically created secrets (a very appealing feature of such systems) and without having to worry about the secrets being view-able from the file system or from inspecting the env variables of the docker container.

Personal Opinion

I believe env variables is the way to go. It's easier to manage, and you can still pull from a secret store like Hashicorp Vault, if you have you CI build system pull the secrets during the build and set them when you deploy. You get the best of both worlds, and the added benefit of your developers not needing to write application code to fetch secrets. Devs should be focused on their code functionality, and not dealing with admin tasks like fetching passwords.

Your application's code should be focused on it's own app functionality itself, and not dealing with backend tasks like fetching passwords. Just like the 12 Factor App states.

Edit: changed last sentence to remove implication of Developer vs SysAdmin silo-ing. The tasks themselves should be separate from a code perspective, but DevOps is about the same persons keeping both in mind and not be limited.

Personal Opinion (Update)

Per @Dirk's excellent comment (Passing secrets to a Docker container), there is a very strong argument to prioritize a secret store over ENV vars, due to not wanting to leak them.

Improve this answer
14
  • 2
    This promotes silos. DevOps is doing things together instead of throwing things over the wall.
    – 030
    Apr 19, 2018 at 15:24
  • 2
    The code should be silo'd off from the infrastructure components. The actual people could code both the infrastructure automation and the app code base, but the tasks themselves should be separate. I see the last sentence of my original answer was silo-ing off the devs, the people. That is a mistake. I'll edit that to be clearer.
    – BoomShadow
    Apr 20, 2018 at 15:03
  • 21
    Putting secrets into environment variables offers various possibilities for them to be leaked. A few examples: Everybody with access to the Docker daemon on the machine running the container can see them using the inspect or exec commands. Environment variables often get dumped to stdout or into logfiles when running in some debug mode. All spawned child processes can read and expose them which might be out of your control. More information e.g. here: diogomonica.com/2017/03/27/…
    – Dirk
    Feb 1, 2019 at 17:03
  • 4
    I am also grappling with this question. The thing I don't understand is, even if you use a credentials vault to secure your secrets, you still must authenticate to gain access to that vault, and that presumably requires some secret. The same concern applies to using a password-protected KeyStore file. Are we always stuck with passing at least the "meta credential" in the environment?
    – Wheezil
    Mar 8, 2019 at 17:43
  • 4
    @Wheezil a meta-credential is easier to secure than many specific credentials. you can frequently and automatically rotate the meta credential. the meta credential can go to a vault that is on a secured host and can have things like ip whitelisting so that it only accepts connections from your production subnets. you can also ensure that the vault uses encryption at rest and encryption in flight and mutual tsl and certificate pinning and all the other best practices that make things more secure.
    – simbo1905
    Mar 9, 2019 at 6:15
2

There is another option only using pipe:

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

First, create the docker daemon with -i, 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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