Docker Secrets: documentation and consistency

[buxm]

trafficstars

Description of the feature I understand that this image supports for Docker secrets, e.g. instead of putting your DB password in the DB_PASS environment variable (which could be accessible outside of the container), put it into a "docker secret" that docker mounts as file in the container file system (e.g. /run/secrets/db_password) and set the env variable DB_PASS_FILE=/run/secrets/db_password. See https://docs.docker.com/engine/swarm/secrets/ for the why's and how to's of Docker secrets.

However I found the documentation about this feature lacking: i.e. no indication of which variable names can be used to point to secret files containing which parameter. E.g.: can I pass the DB name as a secret? Apparently no. Can I pass the DB password as a secret? Yes. Which variable contains the path to the secret file for the DB password? DB_PASS_FILE The answers to these questions don't seem to be in the readme and are not straightforward.

Only digging through the code of 10-db-backup I found out that the variable names that point to secret files use the _FILE suffix (which is common practice, but not dictated by Docker or by any official standard); and that they seem to be only DB_USER_FILE, DB_PASS_FILE, S3_KEY_ID_FILE and S3_KEY_SECRET_FILE. Initially I was trying to use a secret also for the S3 bucket name, but having no success, I had to dig through the code to find out it wasn't me getting something wrong.

Also I am not sure why DB_USER_FILE is used for CouchDB, InfluxDB, MongoDB, but NOT for MySQL, PostgreSQL and Redis. This also came out when I was unsuccessful using a secret for the DB user for my MySQL DB and I had to dig through the code to understand why.

Suggestions:

1. document which variable can contain paths to secret files
2. if there is no technical issue unknown to me, extend the usage of DB_USER_FILE to al the other database types.

Benefits of feature Documenting the "secrets" varialbe would make it easier for the user to get to know the support for Docker secrets and how to use it.

Making the DB username consistently "secret" across all DB types would improve security of implementation and also would make it easier for the user who don't need to know whethera specific secret can be used depending on DB type.