Docker compose secrets - file vs environment

Docker Engine Compose
1

Hello,

Fairly new to Docker, and I’m using docker compose to orchestrate services, both pre-built and custom - InfluxDB, Telegraf, Postgresql, NanoMQ, Backend and Frontend servers .

I’m using Docker Secrets to manage the usernames, passwords, etc.

I see that the secret can be from a file, or environment

secrets:
   my_secret1:
      file: ~/my_secret1.txt
   my_secret2:
      environment: MY_SECRET2

My question is around pros and cons of the two - i.e. file and environment.

Having a .env file with all the usernames, passwords, and tokens (that’s not checked into git) offers the advantage of easier management.

It looks like if I use the file option, I will need one file per secret , so that seems clunkier to manage.

One concern that people had was that the variables in the .env file would be accessible to all the containers, but that doesn’t seem to be true.

I checked with

docker compose exec influxdb2 /bin/printenv
docker compose exec telegraf /bin/printenv

etc, and each container only has the environment variables defined for it.

So far, I’ve not been able to find a definitive answer - just don’t use environment variables directly (which I don’t think I am). Secrets setting secrets from environment variables definitely seem to be a wrinkle that deserves greater understanding from a security perspective, so any information or pointers here would be greatly appreciated!

Thanks,
Sridhar

PS - Upon further searching, I read on Google AI results (so I don’t trust it until I see the source) that the .env file is used for variable subsitition and not passed directly to the containers, which would explain my above observations too. In that case, a well protected .env file that is not version controlled would seem the ideal way to keep all secretly safely in one place, and use that via secrets->environment ? Yes? No?

3

It’s a design choice.

I wrote something about secrets here: Docker Secrets + security_opt - #2 by meyay.

With secrets in environment variables, you must make sure your containerized application does not accidentally leak those environment variables. For instance, a spring boot application using the actuator endpoint, could be misconfigured in a way that it’s possible to query the environment variables. This could be helpful during development, but a catastrophe in production. This wouldn’t happen if the application parses the secret file itself. Of course this does not stop individuals from exposing the secrets themselves. :slight_smile:

@rimelek wrote about env files here: WARN[0000] The "Dir_Conf_n5105" variable is not set. Defaulting to a blank string - #3 by rimelek. Make sure to follow the link to the quoted resource at the end of the post.

4

Thanks for the reply and the links.

This statement from the second link explains it best:

Again, the .env file or anything you set as a parameter of docker compose to override the default is only for using variables in the compose file. Not in containers.

Therein lies some of the confusion. In my case, I’m using the .env file to pass variables into the compose file. For the actual services, I’m using docker secrets to pass sensitive values (which I derive from the .env file used by the compose file. I’m not using environment variables to pass values to the services.

With docker secrets (in the compose file), it can get the value from “file” or “environment” . This docker secret from “environment” is ok to use as it’s only that of the compose file, and doesn’t propagate to the services.

Of course, one has to be careful to omit the .env (or other named environment file for use in docker compose only) from source control.

At least, that’s my understanding now after reading the docs and the various sources (including yours!).

Thanks,
Sridhar

5

It’s a must entry in the .gitignore file.

Your conclusion looks spot on to me :slight_smile:

Have a great weekend!