3 ms·

Yeah, I've never been a fan of secrets in env vars for this reason. It is shocking how frequent dumb debug consoles have accidentally exposed env vars. You real

by _ea1k 3y ago

Yeah, I've never been a fan of secrets in env vars for this reason. It is shocking how frequent dumb debug consoles have accidentally exposed env vars. You really don't want that to accidentally expose your private keys. There's really nothing wrong with secrets mounted on the file system via k8s. But, of course, all of this depends on your deployment environment. Sometimes env vars are the least bad option, because secrets really are always hard.

berkes 3y ago
> dumb debug consoles have accidentally exposed env vars Huh? If the app can read the secret, then the app can... read the secret. Maybe I'm misunderstanding what you call a "debug console", but if this is anything running in the app, it can ... read the secrets. Regardless of their source. Or, to put it differently: it matters nothing if your secrets at rest are stored in a quantum-resistent-encrypted vault, secrets.yml or ENV vars, if your logging, backtracing or debug consoles dump them somewhere, you are compromised regardless.
- _ea1k 3y ago
  This is absolutely true, but it is far more common for someone to accidentally leave open a display of env vars than a display of files. I've got this problem to debug in prod, I know, I'll embed the env vars in the source code of the error page. No big deal and it might help me debug that! For a dev used to not using secrets in env vars (for example, when testing locally), this is an easy mistake. He may even use a third party library that embeds features like this without knowing it! Even things like the jmx console can be risky, since access to that may not relate 1:1 with access to secrets. I've never seen anyone make a similar mistake and accidentally embed all_my_passwords.ini in their output. I must admit that some of what I've said above has become outdated, since it is now a much more common practice to embed passwords in env vars than it used to be.
  - berkes 3y ago
    Wholeheartedly disagree. I've yet to come across any git repo that didn't, at some point, commit the all_mypasswords.ini (or, just as bad, the .env.backup). I've only once ever seen a repo that had ENV vatlrs committed (where some moron committed the entire ./dist directory which included a Json that held the copy of ENV at compile time) My point is not that "one is obviously better", but that none is obviously better. All solutions have downsides. Implementing 12 factor means understanding those.

by _ea1k 3y ago

berkes 3y ago

> dumb debug consoles have accidentally exposed env vars Huh? If the app can read the secret, then the app can... read the secret. Maybe I'm misunderstanding what you call a "debug console", but if this is anything running in the app, it can ... read the secrets. Regardless of their source. Or, to put it differently: it matters nothing if your secrets at rest are stored in a quantum-resistent-encrypted vault, secrets.yml or ENV vars, if your logging, backtracing or debug consoles dump them somewhere, you are compromised regardless.

_ea1k 3y ago
This is absolutely true, but it is far more common for someone to accidentally leave open a display of env vars than a display of files. I've got this problem to debug in prod, I know, I'll embed the env vars in the source code of the error page. No big deal and it might help me debug that! For a dev used to not using secrets in env vars (for example, when testing locally), this is an easy mistake. He may even use a third party library that embeds features like this without knowing it! Even things like the jmx console can be risky, since access to that may not relate 1:1 with access to secrets. I've never seen anyone make a similar mistake and accidentally embed all_my_passwords.ini in their output. I must admit that some of what I've said above has become outdated, since it is now a much more common practice to embed passwords in env vars than it used to be.
- berkes 3y ago
  Wholeheartedly disagree. I've yet to come across any git repo that didn't, at some point, commit the all_mypasswords.ini (or, just as bad, the .env.backup). I've only once ever seen a repo that had ENV vatlrs committed (where some moron committed the entire ./dist directory which included a Json that held the copy of ENV at compile time) My point is not that "one is obviously better", but that none is obviously better. All solutions have downsides. Implementing 12 factor means understanding those.