Compose, passwords and security


It’s been some days I’m looking for a clear answer but can’t find it.
I want to create my compose files without storing passwords and api tokens in them.
I’m not running in swarm mode and don’t wan’t to.

Looking at all the answers, some says that I should use environment variables (but seems to be unsecure) or use secrets in compose file.

What I don’t understand with secrets is how to use them in every compose/containers ?
Some of them have FILE or FILE_ environment variables which are able to read passwords from files.
The others don’t expose such environment variables.

So, lets’ say I want to secure my duckdns API token, wll this compose file be ok ?

version: '3.8'
    container_name: duckdns
      - SUBDOMAINS=mySubDomain
      - TOKEN=/run/secrets/duckdnstoken  <==== HERE
    restart: always
      - /config/duckdns/config:/config
      - server_network	  
      - duckdnstoken
    file: /run/secrets/duckdns.txt
    external: true


A secret is just a file mounted in read-only mode via tempfs mount point. The image must support to read the secret from the file, thus you can not just point an environment variable to a secret (file) and expect it to read the content automatically. If reading a secret from a file is supported by an image, it should be mentioned in the dockerhub description.

In case of doubte, re-read the dockerhub description and check whether it supports reading secrets from a file.

Note: On a single node docker instance, a secret is not really more secure than binding the file as volume in read-only mode. It’s a whole different thing on a multi node swarm cluster, where secrets are distributed encrypted amongst the nodes, and only accessible in clear-text once mounted inside a container.

Thanks for your answer, this is what i thought regarding to all what i read.
So, is there a good way to manage passwords etc through compose files without using swarm mode ?
What is the best practice / most common practice ?

If you are an application developer and aim for best practices, you could implement logic in your application to use a secret manager like hasicorp vault, aws secret manager, azure key vault. Usually the secret manager to choose depends on your operational environment, or what you organization provides.

Though, if you are just an image maintainer or consumer, the common practice is what you already know: set credentials as environment variables, or if the image supports it as secret file. You can not prevent a container to access both kind of secrets.

Ok thank you.
I’m just a container consumer creating its own NAS server :slight_smile:

Have you looked into .env files? That way you don’t have to store credentials in the compose file. Doc.