Compose, passwords and security

Docker Engine Compose
,
1

Hi,

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'
services:
  duckdns-svc:
    image: lscr.io/linuxserver/duckdns:latest
    container_name: duckdns
    environment:
      - SUBDOMAINS=mySubDomain
      - TOKEN=/run/secrets/duckdnstoken  <==== HERE
    restart: always
    volumes: 
      - /config/duckdns/config:/config
    networks:
      - server_network	  
    secrets:
      - duckdnstoken
      
secrets:
  duckdnstoken:
    file: /run/secrets/duckdns.txt
    
networks:
  server_network:
    external: true

Thanks

2

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.

3

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 ?

4

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.

5

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

1 Like
6

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

7

Hi all. I know this is an old thread, but I am having same questions about storing sensitive credentials in the compose file. My setup is such that the compose files are only stored locally on my development pc, which isn’t publicly accessible. Sensitive info is never stored on the servers the docker services and applications are running on for my websites, load balancers and any server that is on a vps or are exposed to the public internet.
I execute the compose file from my dev pc commanline to create the service/app on the remote hosts using docker contexts.
In my view, this is safer than storing the info on the publicly accessible docker vps, server, or storing the credentials on a file (even .env file) on anywhere they can be breached. Is this the right, safer approach? Or am I mising something?

8

A container will always be able to access a secret, regardless whether it is available as environment variable, or as file. Be sure your application does not have a publicly accessible endpoint that allows to see environment variables and or the application configurations. For instance, it is perfectly possible to configure a (Java) Spring Boot actuator endpoint to leak those details.

In case the secret is stored in an environment variable, it will be stored as part of the container configuration, and can be extracted by a simple docker container inspect {container name or id} by everyone that has access the docker socket.

1 Like