| ▲ | akoboldfrying 4 hours ago | |
> Besides being bad advice What makes it bad advice? > this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files You need some way to pass secrets to the app; doesn't every other way also suffer the same kind of issue? | ||
| ▲ | nebezb 4 hours ago | parent | next [-] | |
> You need some way to pass secrets to the app Absolutely. This is why the env method is so attractive. It's simple and feels "free". > doesn't every other way also suffer the same kind of issue Not entirely. Accessibility (or dev ergonomics) and security are opposite ends of the same dial. As the other commenter wrote: a workload identity and a vault, and sharing the secrets between the two in a way that doesn't leave a plain-text trace for everyone to read (the environment is not private). I like sops: https://github.com/getsops/sops | ||
| ▲ | patmorgan23 4 hours ago | parent | prev | next [-] | |
Secrets should go in a vault and retrieved with the help of a workload identity. | ||
| ▲ | skybrian 2 hours ago | parent | prev [-] | |
Now that we use coding agents, you don't want to store secrets anywhere in the same VM, because that makes them vulnerable to exfiltration. The best way is to access external services via a proxy that holds the secrets. exe.dev has a zillion of them: https://exe.dev/docs/integrations | ||