<p>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. </p>

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

<ul>
<li>Values are encrypted on the manager hard drives, though typically, the decryption key is also there to make restarting managers easier.</li>
<li>Values are not written to disk on workers, they are injected as a file on a tmpfs filesystem mounted into the container.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ul>

<p>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.</p>

CC BY-SA 4.0
2018-09-28T22:18:37.330Z
Thank you. The missing part were the backups. Since I'm responsible for them and my plan is to backup just the database. So will not have the risk with images. Anyway why I should want to backup them? I have the docker files to  simply restore them.

I skimmed through the documentation on Docker swarm. As I understand correctly Its not usable with Docker CE on own Servers (on premise). Just for passing secrets it has too much features and a price tag.
user3142459
CC BY-SA 4.0
2018-09-28T22:37:40.750Z
Docker's swarm mode is included with the CE engine. Implementing it is often as easy as `docker swarm init`. And deploying your containers if you have a compose file is `docker stack deploy -c compose.yml stack_name`.
BMitch
CC BY-SA 4.0
2018-09-28T19:09:09.543Z
2018-09-28T19:09:09.543Z
BMitch
<p>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. </p>

<p>Besides ENV variables, you could also consider using an external secrets repository, such as Hashicorp <a href="https://www.vaultproject.io/" rel="nofollow noreferrer">Vault</a>, or possibly even AWS secrets. See also <a href="https://github.com/hashicorp/vault" rel="nofollow noreferrer">vault's github page</a>. 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.</p>

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

<ul>
<li><a href="https://medium.com/@mccode/dont-embed-configuration-or-secrets-in-docker-images-7b2e0f916fdd" rel="nofollow noreferrer">https://medium.com/@mccode/dont-embed-configuration-or-secrets-in-docker-images-7b2e0f916fdd</a></li>
<li><a href="https://techbeacon.com/how-keep-your-container-secrets-secure" rel="nofollow noreferrer">https://techbeacon.com/how-keep-your-container-secrets-secure</a></li>
</ul>

CC BY-SA 4.0
2018-09-28T22:10:27.197Z
Thank you. I looked up habitus.io in detail. But I wasn't able pass credentials. So I gave up and came to the question if it is all worth in my case.
user3142459
CC BY-SA 4.0
2018-09-28T14:34:11.730Z
2018-09-28T16:22:58.210Z
2018-09-28T16:22:58.210Z
Gavin
<p>I'm new to Docker and want to put my Django web application into containers.</p>

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

<p>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.</p>

<p>The setup</p>

<ul>
<li><p>I provide the credentials via .env file of docker compose. This file is not on version control.</p></li>
<li><p>The containers are running as non-elevanted users (a different special user).</p></li>
<li><p>Docker command on the host can be used as root only.</p></li>
<li><p>I'm the only user of the host server (Ubuntu 18.04).</p></li>
<li><p>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. </p></li>
<li><p>I don't want to use kubernetes or swarm. </p></li>
</ul>

<p>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?</p>

<p>Thank you in advance</p>

<docker><linux><security>
Docker security risks passing secrets over environment variables
user3142459
# Docker security risks passing secrets over environment variables

(Asked by: username_0 on 2018-09-28)

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

**Tags:** docker, linux, security


---

## 2 answers

### Answer by username_1 on 2018-09-28. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_0**: Thank you. The missing part were the backups. Since I'm responsible for them and my plan is to backup just the database. So will not have the risk with images. Anyway why I should want to backup them? I have the docker files to  simply restore them.  I skimmed through the documentation on Docker swarm. As I understand correctly Its not usable with Docker CE on own Servers (on premise). Just for passing secrets it has too much features and a price tag.  
> **username_1**: Docker's swarm mode is included with the CE engine. Implementing it is often as easy as `docker swarm init`. And deploying your containers if you have a compose file is `docker stack deploy -c compose.yml stack_name`.  

---

### Answer by username_2 on 2018-09-28. Score: 1

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](https://www.vaultproject.io/), or possibly even AWS secrets. See also [vault's github page](https://github.com/hashicorp/vault). 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>

> **Comments:**
> **username_0**: Thank you. I looked up habitus.io in detail. But I wasn't able pass credentials. So I gave up and came to the question if it is all worth in my case.  

---

