Consider support for Docker Secrets

[chrishoage]

Docker (and by extension compose) supports Docker secrets which let you better protect data.

Secrets can be used with out a swarm in docker-compose by pointing to a file. For example

secrets:
   samba_chris_password:
     file: /root/secrets/samba_chris_password

These can then be used in the service config

     secrets:
       - samba_chris_password
     environment:
       FILE__SAMBA_CHRIS_PASSWORD: /run/secrets/samba_chris_password

The service can then read the file referenced in the environment variable using the value.

This offers slightly better security than having the the password referenced directly in the docker compose file.

While yes, one could read the secrets file themselves feeding in the environment variable to docker-compose manually, it would be nice to use built-in dockerisms to achieve this behavior. It would also open up better support for consumers of the service which might be using a local swarm and managing the secrets that way.

I realize that reading just the password may be cumbersome, so an alternative is storing each user in a secret. For example FILE__USER, FILE__USER2 and so on.

If this is something that would be considered I am open to filing a PR. It actually seems fairly straight forward to extend

while read i; do
    eval user $(sed 's/^/"/; s/$/"/; s/;/" "/g' <<< $i)
done < <(env | awk '/^USER[0-9=_]/ {sub (/^[^=]*=/, "", $0); print}')

offering a separate read loop that looks for FILE__USER environment variables that cat before calling the user utility function

A quick test shows that simply adding

while read i; do
    eval user $(sed 's/^/"/; s/$/"/; s/;/" "/g' <<< $(cat $i))
done < <(env | awk '/^FILE__USER[0-9=_]/ {sub (/^[^=]*=/, "", $0); print}')

is enough to make it work, though in the PR I'd add a sanity check to ensure $i is a file first

[akrea]

Second that to harden server security!