I have this use case: I'm deploying Play applications using Docker, and as you know, it's really easy to pass environment variables and set values on application.conf:
application.key.secret = ${?APPLICATION_KEY_SECRET}
But, Docker Swarm works different. It does not load
secrets into the containers as environment variables. Instead, it loads them as files like:
/run/secrets/com.company.application.key.secret
Right now, I'm doing this as workaround:
1) Register the secrets on Docker Swarm like
com.company.application.key.secret=SECRET_VALUE
com.company.application.db.password=SECRET_PASSWORD
[...]
Every secret will be loaded as files into the containers:
/run/secrets/com.company.application.key.secret
/run/secrets/com.company.application.db.password
[...]
2) Use an entrypoint.sh file for the Play Application's Docker container. It reads the files and sets environment variables:
export APPLICATION_KEY_SECRET=$(cat /run/secrets/com.company.application.key.secret)
export APPLICATION_DB_PASSWORD=$(cat /run/secrets/com.company.application.db.password)
[...]
3) Set the variables on application.conf as usual
key.secret = ${?APPLICATION_KEY_SECRET}
db.password = ${?APPLICATION_DB_PASSWORD}
[...]
}
It works, but as you can see, it's not the best way to do it. So far I understand, the idea of use the file system instead of environment variables is because the last ones are insecure as long as they can be read for any process. In that sense, well, let's say that the workaround is not making things better.
Proposal: enable a way to set values on application.conf, using the file system. It would be something like this:
application{
key.secret = @{?/run/secrets/com.company.application.key.secret}
db.password = @{?/run/secrets/com.company.application.db.password)
[...]
}
Looking forward for your comments or questions.
Best,
Mario