currently it is possible to mount a secret file. But only as a file. If the content of the file has to become the content of a environment variable, then you have to do extra work. And this is only possible, if the docker image supports a shell. But some minimalist docker images don’t have even a shell. Then you can’t use docker secret files at all.
So it would be great, to add a feature, that the content of a docker secret is mounted as the content of a environment variable. K8s has a similar feature. And it would be very helpful also in context of docker compose.
Note that environnement variables are not secret at all. Having access to a shell it’s then easy to do a printenv (Linux cli cimmand) and hop everything is visible.
Plain text mounted files are also no “secrets” at all. I agree, that the _FILE environment postfix name approach is better, then having the secret values as environment variable directly, but also not all services support the _FILE environment postfix name approach. And not all docker images have a shell, to create an own work around
Secrets available for Swarm. The one that compsoe supports is just mounting files to where real secrets would be mounted. You can use an external tool to manage ecrets and run the containers in the environment where the secrets are decrypted.
I wrote about sops here:
When you encrypt a secret using sops and the file called secret.yml containing
You could also try storing the decrypted password on tmpfs if you run a sidecar container that uses a shared memory with your main container and the sidecar can decrypt the secret file into the shared folder. I can write about that later.
I just use the official term of Secrets in Compose | Docker Docs
I’m fully aware, that these secrets are not encrypted. Just handled in a different way. Similar to k8s.
The disadvantage of the ENV files is, that you have to define the environment variable in the shared env file.
But if different services require different environment variable names, then you have to duplicate the files and their content, just using different environment variable names.
Hence you have no chance to maintain only one value and reuse it in multiple use cases.
You can have a common env file and separate env files for values that are different in different services. You can even have a default values and override some of the values in a second env file. Wouldn’t that help?
Let’s say, you have to share a technical user credential between the db and two different service
the service a requires the environment variable names DB_USER and DB_PASSWORD and the service b requires the environment variable names spring.datasource.username and spring.datasource.password
With the env file approach I’ve to create either one big env file with multiple entries like
A file called .env is automatically read by Docker Compose and you can use the values in the compose file and pass to different variables in different services.
I totally agree with you, that the _FILE approach is the best, but why I should I make it more insecure for all services, if only one service does not support that nice feature?