Managing Secrets in Docker Compose – A Developer's Guide
12 comments
·February 3, 2025jiehong
What would be nice is if we could have a standard way to requests secrets from a store, like from the keychain on Mac or from a key vault in production, or from any password manager on a phone.
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.
hahnbee
We use Infisical for this. Are you doing anything different?
TZubiri
As soon as you automate it it stops being secure.
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.
skeeter2020
We have 3500 installs; you think having a human manage all those secrets manually is best practice?
null
DiggyJohnson
Okay…what if you do need multiple instances for one a million reasons?
shard972
[dead]
arianvanp
The amount of damage "12 factor" did to the security of our applications is so big. I'm happy that we're turning around and realizing again files are the way forward for secrets.
DiggyJohnson
Can you summarize the nature of this damage? I think I’m lucky to have missed that part of software development orthodoxy
arianvanp
I think the article is pretty good at summing it up.
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.
null
The problem with this article is it assumes you control how an app wants secrets. In my stacks, I end up running a bunch of services that all have different configuration paradigms. This is why I wrote the dcsm to help me store encrypted secrets in git, template them into environment or config files, and need only to distribute the decryption key out of band.
https://igor.moomers.org/posts/secrets-in-docker-compose