4 ms·

> 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

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

patmorgan23 1mo ago
Secrets should go in a vault and retrieved with the help of a workload identity.
- akoboldfrying 1mo ago
  How does the running app instance get the workload identity? The ways I can think of are (1) it's baked into the source code (worst possible security), (2) it's provided on the command line (also bad since command lines are visible to ps unless you do various OS-specific hijinks), (3) it's provided in an environment variable (no better than before), or (4) it's read from some well-known path (it seems to me that anything that could read a process's env vars could also read the contents of this file, so how is this more secure?)
  - minitech 1mo ago
    > (3) it's provided in an environment variable (no better than before) Even if you take no measures beyond simply using a token that can be exchanged for secrets (and you can – invalidate it, authenticate it, etc.), you’re already doing better than before, because the token isn’t useful to an attacker without access to the secret store, whereas something like a JWT secret key is very useful.
    - akoboldfrying 1mo ago
      Thanks, I can see how invalidating the token after first use, or after a short time period, reduces the exploit possibilities. (If all upstream service providers that you depend on were perfect, this could be arranged separately for each JWT that you need, but they aren't perfect.) > authenticate it > the token isn’t useful to an attacker without access to the secret store If it's not a bearer token (that is, if you need to provide some additional credentials to authenticate it to the secret store) then any such additional authentication would need to be passed in somehow. Are you maybe assuming that in the environment where the app runs, some subsystem will have already installed a credential for some suitable IAM security principal? Because in that case, I certainly agree that it's better to anchor everything off that. That covers many cases (including every cloud) but not, e.g., rented plain VPSes or a couple of servers in your own basement.
nebezb 1mo ago
> 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 https://github.com/getsops/sops
skybrian 1mo ago
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 https://exe.dev/docs/integrations

patmorgan23 1mo ago

Secrets should go in a vault and retrieved with the help of a workload identity.

akoboldfrying 1mo ago
How does the running app instance get the workload identity? The ways I can think of are (1) it's baked into the source code (worst possible security), (2) it's provided on the command line (also bad since command lines are visible to ps unless you do various OS-specific hijinks), (3) it's provided in an environment variable (no better than before), or (4) it's read from some well-known path (it seems to me that anything that could read a process's env vars could also read the contents of this file, so how is this more secure?)
- minitech 1mo ago
  > (3) it's provided in an environment variable (no better than before) Even if you take no measures beyond simply using a token that can be exchanged for secrets (and you can – invalidate it, authenticate it, etc.), you’re already doing better than before, because the token isn’t useful to an attacker without access to the secret store, whereas something like a JWT secret key is very useful.
  - akoboldfrying 1mo ago
    Thanks, I can see how invalidating the token after first use, or after a short time period, reduces the exploit possibilities. (If all upstream service providers that you depend on were perfect, this could be arranged separately for each JWT that you need, but they aren't perfect.) > authenticate it > the token isn’t useful to an attacker without access to the secret store If it's not a bearer token (that is, if you need to provide some additional credentials to authenticate it to the secret store) then any such additional authentication would need to be passed in somehow. Are you maybe assuming that in the environment where the app runs, some subsystem will have already installed a credential for some suitable IAM security principal? Because in that case, I certainly agree that it's better to anchor everything off that. That covers many cases (including every cloud) but not, e.g., rented plain VPSes or a couple of servers in your own basement.

nebezb 1mo ago

> 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 https://github.com/getsops/sops

skybrian 1mo ago

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 https://exe.dev/docs/integrations