Manage sensitive data with Docker secrets

As per v3.4, the following passwords are injected by the host as environment variables:

Ref: https://blog.diogomonica.com//2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/

When you store your secret keys in an environment variable, you are prone to accidentally exposing them—exactly what we want to avoid. Here are a few reasons why ENV variables are bad for secrets:

Given that the environment is implicitly available to the process, it's hard, if not impossible, to track access and how the contents get exposed (ps -eww <PID>).
It's common to have applications grab the whole environment and print it out for debugging or error reporting. So many secrets get leaked to PagerDuty that they have a well-greased internal process to scrub them from their infrastructure.
Environment variables are passed down to child processes, which allows for unintended access. This breaks the principle of least privilege. Imagine that as part of your application, you call to a third-party tool to perform some action—all of a sudden that third-party tool has access to your environment, and god knows what it will do with it.
When applications crash, it's common for them to store the environment variables in log-files for later debugging. This means plain-text secrets on disk.
Putting secrets in ENV variables quickly turns into tribal knowledge. New engineers who are not aware of the sensitive nature of specific environment variables will not handle them appropriately/with care (filtering them to sub-processes, etc).

Overall, secrets in ENV variables break the principle of least surprise, are a bad practice, and will lead to the eventual leak of secrets.

Ref: https://docs.docker.com/engine/swarm/secrets/#use-secrets-in-compose

This example creates a simple WordPress site using two secrets in a compose file:

the keyword secrets: defines two secrets db_password: and db_root_password:.
when deploying, Docker creates these two secrets and populates them with the content from the file specified in the compose file.
the db service uses both secrets, and the wordpress is using one.
when you deploy, Docker mounts a file under /run/secrets/<secret_name> in the services. These files are never persisted in disk, but are managed in memory.
each service uses environment variables to specify where the service should look for that secret data.

More information on short and long syntax for secrets can be found at Compose file version 3 reference.

version: "3.9"

services:
   db:
     image: mysql:latest
     volumes:
       - db_data:/var/lib/mysql
     environment:
       MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password   # <-- MYSQL_ROOT_PASSWORD
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD_FILE: /run/secrets/db_password             # <-- MYSQL_PASSWORD
     secrets:
       - db_root_password
       - db_password

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "8000:80"
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD_FILE: /run/secrets/db_password      # <-- WORDPRESS_DB_PASSWORD
     secrets:
       - db_password

secrets:
   db_password:
     file: db_password.txt
   db_root_password:
     file: db_root_password.txt

volumes:
    db_data:

g3w-suite / g3w-suite-docker

Manage sensitive data with Docker secrets #71