Hacker News new | past | comments | ask | show | jobs | submit login
Managing Secrets in Docker Compose – A Developer's Guide (phase.dev)
62 points by thunderbong 5 days ago | hide | past | favorite | 13 comments





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


Hey, I smell sysadmins stuff in that lines

> 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"


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.

Can you summarize the nature of this damage? I think I’m lucky to have missed that part of software development orthodoxy

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.


We use Infisical for this. Are you doing anything different?

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.


We have 3500 installs; you think having a human manage all those secrets manually is best practice?

Is doing something 3500 times ridiculous? Or is it standard issue work?

By the by, the frequency of this is once per server, so it's not like you have to do it daily.


Okay…what if you do need multiple instances for one a million reasons?

Transfer your secrets manually multiple times



Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: