Docker security risks passing secrets over environment variables

Question

I'm new to Docker and want to put my Django web application into containers.

For the last couple days I'm struggling with passing credentials safe to containers.

Online there is always the hint that secrets should not be passed as environment variable because they can be retrieved via inspect or from the images. My hope is that it can be neglected for my setup.

The setup

• I provide the credentials via .env file of docker compose. This file is not on version control.

• The containers are running as non-elevanted users (a different special user).

• Docker command on the host can be used as root only.

• I'm the only user of the host server (Ubuntu 18.04).

• I assume breaking into the host is much harder (I'm using SSH public key authentication with non-root user only) than breaking into container of the Django app.

• I don't want to use kubernetes or swarm.

I'm newbie to Docker and not a security expert. Do I have overlooked something? Why should I care about the docker inspect or images in this setup?

Thank you in advance

Answer 1

As long as no one else is logging into the server or able to run docker commands against the host, then passing secrets as an environment variable into the container which is only stored on the host is relatively secure. About the only risk I can think of is that it is a clear text value on the disk, so you have the risk of the secret escaping with a lost harddrive or backup.

Docker's swarm mode secrets have the following advantages over environment variables and other ways of managing secrets:

• Values are encrypted on the manager hard drives, though typically, the decryption key is also there to make restarting managers easier.
• Values are not written to disk on workers, they are injected as a file on a tmpfs filesystem mounted into the container.
• Values are not able to be displayed with an inspect command on the service, container, or the secret itself. You must deploy a service with the secret to get access to that secret.
• Secrets are automatically sent to workers on a need to know basis from the managers, no need to build an external process to synchronize files across hosts.
• The secret file may be limited with unix filesystem permissions, e.g. only enabling root read access, and having your container drop access to another user after loading the secret.

That said, no matter what, all secret management solutions are a way to give your application a clear text password or other credential. And with a process, every way of doing that has some level of risk. One of the best ways to reduce that risk is to make sure every service gets its own individual secret, with only the access needed by that specific service, and that it is frequently rotated. It's also useful to look at additional layers of security, like network policies you can configure with service mesh solutions.

Answer 2

ENV variables are a good way of passing secrets to a container. What you don't want to do is bake the secrets directly in the image. As you have rightly done, do not store secrets in your source control repo as well.

Besides ENV variables, you could also consider using an external secrets repository, such as Hashicorp Vault, or possibly even AWS secrets. See also vault's github page. Your container would still need a token/credentials required to Authenticate/Authorize with the key store, but if required, these can be made to expire/rotate.

So you are on the right path. Some additional reading is worthwhile at this point:

• https://medium.com/@mccode/dont-embed-configuration-or-secrets-in-docker-images-7b2e0f916fdd
• https://techbeacon.com/how-keep-your-container-secrets-secure