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.
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"
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.
That is very debatable.
It depends on ones assessment on the risk of passively leaking a file on a poorly cleaned up "cloud" disk is lower or higher from an actual intruder getting access to environment variable.
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.
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.
https://igor.moomers.org/posts/secrets-in-docker-compose
reply