3 ms·

While theoretically valid, in practice, nothing beats env vars and I have yet to see problems. If it leaks, you can change it anyway. If somebody is on the serv

While theoretically valid, in practice, nothing beats env vars and I have yet to see problems. If it leaks, you can change it anyway. If somebody is on the server, env vars are the least of your problems (also they are session wise and not saved locally). You should always use both - keep passwords in secret manager and during build communicate them to relevant parts of app via env vars. That way, you can easily reproduce it locally without secret manager available or slowing you down (maybe you need VPN to access it?, GitLab access to secrets etc.). Also, you can't easily change them for testing purposes or store variations of them - perhaps you mix several production with several testing environments. Contrary to that, you can keep dozen of them and easily change them in a single file while developing. Thee are bunch of tools to hide leaking environment vars too by masking them. So, no, this is not obsolete. Maybe it doesn't make sense in some scenarios but such cases shouldn't be the norm.

preseinger 4y ago
This is straight-up bad advice. Shuttling secrets via env vars expose you to strictly more risk vectors than through properly permissioned files on disk. Point blank, no argument. It's not acceptable to use env vars for secrets.
CraigJPerry 4y ago
I wouldn't want to change the usage of env vars, they're ergonomic and only the current user or root can see the env vars of a running process which makes it easy for us to architect secure usage patterns. But... it'd be cool if we had better support for avoiding accidental leaks. E.g. a way to identify another process as my user that ends up reading /proc/<pid>/environ unexpectedly. You could model that with SELinux but it could be a bear to own and not worth it for outside of large/important/high-value target companies. I suppose that's an apt description of SELinux generally... Maybe we could have a "light" version at the code level, maybe use the type system to throw an exception if you ever try to .toString() a secret. I'm trying to think how i would do that in Java without binding someone to an awkward type hierarchy (yuk!). This is not (currently) valid Java: interface Secret { default sealed String toString() { throw new IllegalAccessException() } } By this i mean a type that if i compose with, then it overrides (not currently supported) my toString() and blocks me changing the impl of that (sealed), then i can't accidentally log it for example. I think the way to do this in Java today would need to be via a dedicated class, i don't think i could use a composable interface. I mean that's fine-ish but i feel allergic to constraining other developers to my abstract class Secret { ... } EDIT: just blocking /proc/<pid>/environ wouldn't be enough, the other process could ptrace(2) for example.
- majkinetor 4y ago
  Its way more probable that it will leak some other way, like in logs IMO. Who knows what can other process running on the same machine do - it can change stuff in memory of another process so preventing env vars leakage sounds like non issue compared to that. Sure, there are more easily available tools OTB on most systems to do that but somebody needs to run them anyway...

preseinger 4y ago

This is straight-up bad advice. Shuttling secrets via env vars expose you to strictly more risk vectors than through properly permissioned files on disk. Point blank, no argument. It's not acceptable to use env vars for secrets.

CraigJPerry 4y ago

I wouldn't want to change the usage of env vars, they're ergonomic and only the current user or root can see the env vars of a running process which makes it easy for us to architect secure usage patterns. But... it'd be cool if we had better support for avoiding accidental leaks. E.g. a way to identify another process as my user that ends up reading /proc/<pid>/environ unexpectedly. You could model that with SELinux but it could be a bear to own and not worth it for outside of large/important/high-value target companies. I suppose that's an apt description of SELinux generally... Maybe we could have a "light" version at the code level, maybe use the type system to throw an exception if you ever try to .toString() a secret. I'm trying to think how i would do that in Java without binding someone to an awkward type hierarchy (yuk!). This is not (currently) valid Java: interface Secret { default sealed String toString() { throw new IllegalAccessException() } } By this i mean a type that if i compose with, then it overrides (not currently supported) my toString() and blocks me changing the impl of that (sealed), then i can't accidentally log it for example. I think the way to do this in Java today would need to be via a dedicated class, i don't think i could use a composable interface. I mean that's fine-ish but i feel allergic to constraining other developers to my abstract class Secret { ... } EDIT: just blocking /proc/<pid>/environ wouldn't be enough, the other process could ptrace(2) for example.

majkinetor 4y ago
Its way more probable that it will leak some other way, like in logs IMO. Who knows what can other process running on the same machine do - it can change stuff in memory of another process so preventing env vars leakage sounds like non issue compared to that. Sure, there are more easily available tools OTB on most systems to do that but somebody needs to run them anyway...