Add Variable GLPI_DB_PASSWORD_FILE like docker secret as do it MariaDB image

[NicolasGuilbaud]

Hello !

Can you implement Variable GLPI_DB_PASSWORD_FILE like docker secret as do it MariaDB image ?

See https://hub.docker.com/_/mariadb#secrets

Thanks a lot for your work !

[KerhisInfra]

+1

[orthagh]

Hello
Sorry for this late answer.

Could you explain why it could be better that using the current .env file ?
The latter mechanism is similar to a secret file and have the advantage to be used also without any file.

Regards

[leonkroon]

Hello, I would like to answer the question, and propose an idea.

Passing sensitive information through environment variables, whether this is through a file or command, is insecure. Because it exposes the sensitive information.

All passed (sensitive) environment variables are available at the following locations:

• Runtime: inside the container as globally available environment variables, through the env command and possibly other ways of dumping these globally available environment variables
• Config: in the defined container specification, which can be viewed with docker inspect [container-id]

This means that anyone who dumps the configuration of the container, whether it is running or stopped, gets access to the sensitive information, like the password to access the GLPI database.

This is where secrets come in. A secret gets exposed inside the container at runtime, at a file that only exists in memory. This replaces passing sensitive information through environment variables.

This solves all of the previous points of where a sensitive value could be exposed:

• Runtime: there are no sensitive environment variables, only a file containing the secret available in memory at /var/run/secrets/[secret-name]
• Config: there is no plain text secret in the configuration of the container, only a reference to a secret

Initially, the implementation with _FILE seems very similar to how the .env file is used. Unlike Podman, Docker sadly does not officially support any form of secrets (unless you use Swarm mode).

So the process of passing a secret into the container with Docker is achieved by manually mounting a local file containing the 'secret' inside the container. This is a workaround to achieve the same result as working with secrets in Podman or Kubernetes. Because in the end, it prevents the sensitive information from being exposed in global environment variables and the static container configuration.

To properly support secrets, it might be necessary to modify the GLPI source code itself instead of the configuration for this container image. 

And by implementing secrets, it also opens a door to external secret management and rotation through vaults like 1Password Connect, Azure Key Vault, AWS Secret Manager and others.

My proposed idea/change:

Check for secrets in the following way:

1. Secrets in Kubernetes and Podman
   • Secrets in Kubernetes and Podman are exposed at the /var/run/secrets/ directory
   • Make the GLPI PHP application load in the content of the file /var/run/secrets/GLPI_DB_PASSWORD if it exists
2. Secrets in Docker Swarm
   • Secrets in Docker Swarm are exposed at the /run/secrets/ directory
   • Make the GLPI PHP application load in the content of the file /run/secrets/GLPI_DB_PASSWORD if it exists
3. The GLPI_DB_PASSWORD_FILE environment variable
   • Make the GLPI PHP application load the content of supplied path of this variable if it exists
4. Environment variables as last resort

I hope this gives an idea of why it is better. I am not a PHP developer, but I can assist in testing the implementation :).