For example from the MySQL Docker image documentation:
Docker Secrets
As an alternative to passing sensitive information via environment variables, _FILE may be appended to the previously listed environment variables, causing the initialization script to load the values for those variables from files present in the container. In particular, this can be used to load passwords from Docker secrets stored in /run/secrets/<secret_name> files. For example:
$ docker run --name some-mysql -e MYSQL_ROOT_PASSWORD_FILE=/run/secrets/mysql-root -d mysql:tag
Currently, this is only supported for MYSQL_ROOT_PASSWORD, MYSQL_ROOT_HOST, MYSQL_DATABASE, MYSQL_USER, and MYSQL_PASSWORD.
By simply adding additional _FILE environment parameters, this change is entirely backwards compatible and will not disrupt any users that make use of the older .env pattern.
Motivation
This pattern is significantly more secure, as .env files have singular user access control. This also removes sensitive information from existing in the container's environment variables, which is a significant security improvement.
Especially for EspoCRM, there may be a realistic case where a development operations manager may want to give users the ability to manage their ESPOCRM_ADMIN_*** credentials, but not have access to the MySQL database credentials. With the existing .env pattern, that access is "all or nothing."
Following Docker's official recommendation in the link above, I recommend making seven (7) additional ***_FILE environment variables in the Dockerfile to match each of the following, existing variables:
ESPOCRM_DATABASE_HOST(often DevOps managing remote databases do not wish to expose their hosts to developers)
ESPOCRM_DATABASE_PORT
ESPOCRM_DATABASE_NAME
ESPOCRM_DATABASE_USER
ESPOCRM_DATABASE_PASSWORD
ESPOCRM_ADMIN_USERNAME
ESPOCRM_ADMIN_PASSWORD
Example Docker Compose File
As an example of what the improved Docker Compose file may look like for your documentation:
Per the Docker's Docker Compose Secrets documentation, most Docker containers are starting to support the recommended
_FILE
suffix for sensitive information, allowing Docker Compose to use the more-securesecrets
top-level element.For example from the MySQL Docker image documentation:
By simply adding additional
_FILE
environment parameters, this change is entirely backwards compatible and will not disrupt any users that make use of the older.env
pattern.Motivation
This pattern is significantly more secure, as
.env
files have singular user access control. This also removes sensitive information from existing in the container's environment variables, which is a significant security improvement.Especially for EspoCRM, there may be a realistic case where a development operations manager may want to give users the ability to manage their
ESPOCRM_ADMIN_***
credentials, but not have access to the MySQL database credentials. With the existing.env
pattern, that access is "all or nothing."Following Docker's official recommendation in the link above, I recommend making seven (7) additional
***_FILE
environment variables in theDockerfile
to match each of the following, existing variables:ESPOCRM_DATABASE_HOST
(often DevOps managing remote databases do not wish to expose their hosts to developers)ESPOCRM_DATABASE_PORT
ESPOCRM_DATABASE_NAME
ESPOCRM_DATABASE_USER
ESPOCRM_DATABASE_PASSWORD
ESPOCRM_ADMIN_USERNAME
ESPOCRM_ADMIN_PASSWORD
Example Docker Compose File
As an example of what the improved Docker Compose file may look like for your documentation:
As an example for implementation of this change, here is how MySQL manages this:
https://github.com/docker-library/mysql/blob/1a703318803fa85bf69cb5d2e5b3f1c4087627b5/docker-entrypoint.sh#L24-L43
And WordPress, as a more dynamic alternative:
https://github.com/docker-library/wordpress/blob/8c2ded17022e67c6accacfae637c5a577ce169af/wp-config-docker.php#L26-L40