3 ms·
Sorry for stream of consciousness here; at the end of the day if the code that handles the sensitive secret is compromised, you’re leaking secrets one of the
by n42 4y ago
Sorry for stream of consciousness here;
at the end of the day if the code that handles the sensitive secret is compromised, you’re leaking secrets
one of the big ways Vault can help is by separating reads and writes. the web UI that stores a secret, exposed to internet, only receives a token that can write that secret for that customer, and only that customer. that service cannot get tokens that allow the code to read secrets. the background jobs, that aren't exposed to internet, do have the ability to generate scoped tokens to read.
it also helps you mitigate risk by shortening the lifespan of tokens that can access this data. the app container/lambda/process has a Vault token that is only valid for X seconds (whatever you want it to be). This can make it a lot more difficult for an attacker to do anything useful. First they find an exploit, then they try to do something with it. If their token/access is removed every 10 seconds, that makes it a hell of a lot harder to get anywhere once they get in
Vault also increases the discoverability of a compromise by letting you log all accesses to the secrets. this helps manage the aftermath of the compromise by having more certainty in which customers have been impacted etc
It’s all basically risk mitigation. If you have data you need to use legitimately, it’s possible for someone to get it illegitimately. Limit the scope of access they can get with one break in and the length of time they can do anything once they’re in. compartmentalize systems to create defense in depth
Disclaimer: I am not a security expert, but have managed this stuff at startups too small to hire one yet
- _mme 4y agoThank you, very useful!
- _mme 4y agoI have to be annoying, but - if you have a token that is only valid for X seconds - you still need a token to renew the expiring token. I have the feeling that damage control is the only option: 1) Secrets store is on different credentials 2) Decryption key is only known outside of secrets storage 3) There is a maximum number of different credentials that can be queried per day (adjustable over time)
- n42 4y agoYeah you do, but you compartmentalize that with your orchestration (hence strong ops). With HashiCorp Nomad for example you might setup a parameterized job. When Nomad receives a job to do X for customer Y, it allocates a container with a short lived token. Nomad is the system with the longer living token that lets it generate short lived tokens for short lived workloads, that are themselves containerized to add a layer of security for a compromise. And so on. Abstract that a little bit; the system that generates the short lived token ideally would not be the same as the system that is using it Turtles all the way down