Managing Secrets in Docker Compose – A Developer's Guide
phase.dev
phase.dev
> RUN set -eux; \
> groupadd -r postgres --gid=999; \
> useradd -r -g postgres --uid=999 --home-dir=/var/lib/postgresql --shell=/bin/bash postgres; \
> install --verbose --directory --owner postgres --group postgres --mode 1777 /var/lib/postgresql
If we start managing [our] systems, won't we become those weirdo sysadmins we successfully (like 80%) escaped by moving things to Docker? Those guys in sweaters were annoying and moaning on "do this, don't do that, chmod 777 is not good for security"
Environment variables are global, have no access control, and leak across process boundaries. There's sometimes also trickiness with encoding newlines or binary data. It's really tricky to make sure that only the thing you want to give access to the secret has access to the secret and env vars for that reason often end up in logs.
Meanwhile files come with permissions, and handle binary data just fine. And child processes need to explicitly open the file so the chance that some unrelated child processes accidentally logs all your secrets is much smaller than that some sidecar container you run has a log statement that prints all env vars somewhere.
I've seen people misconfigure react projects (like next.js) often where they just expose all their server side secrets as env vars into their client-side javascript due to a process.env call in their build.
Then my containers in compose could just ask for it directly, assuming the request would be routed to the right vault.
No environment variables or files containing a value (I can imagine if there is an empty new line in there at the end…), or json files with special schema for each project.
Manually log in and input or transfer the secrets.
Done.
"But I need new servers to be spun up automatically.."
No you don't. No you don't.
By the by, the frequency of this is once per server, so it's not like you have to do it daily.