2 ms·

One thing bugs me about Vault and I rarely see it beeing discussed: how come a design where Vault simultaniously stores secret AND is able to access other syste

One thing bugs me about Vault and I rarely see it beeing discussed: how come a design where Vault simultaniously stores secret AND is able to access other systems these secrets are for is deemed as good and secure? Vault is a company-wide "root account", reachable from every part of internal network, storing all the company secret data and have reach to many internal and external systems like databases, where it have full rights to dynamically configure short lived credentials. Doesn't it put too much trust into a single system?

thequailman 7y ago
To me, this represents a fatal flaw in Vault's architecture. What it does should be table stakes/standardized and operate in a distributed fashion via integration into the underlying secrets engines. I'm honestly surprised the CNCF hasn't found a project out there to challenge Vault, we desperately need alternatives.
lstamour 7y ago
The real question might be if having it in one place makes monitoring and revocation easier than distributed trusted systems? Also, traditional passwords/secrets don’t expire, and if they do expire, how would you maintain trust in a distributed fashion outside of... complicated multi-part keys, something less secure like DNS, and/or more permanent tokens like the private keys used by a CA system? Somebody somewhere has to maintain a private or secret key, or you need a human to intervene. And even if you store the key on hardware, any users of the key could be compromised. I guess what I’m getting at is—there probably isn’t a perfect answer, just tradeoffs. And if history has taught us anything, it’s a case of “when” not “if” something is attacked/broken. If so, perhaps you should partition your data, including infrastructure, to not rely on just one Vault server for everything? Outside of that, or monitoring, the only other clear answer everyone leans on is “Store it in the cloud,” under the assumption that the hardware and people processes at cloud companies will be more secure overall than anything you’d develop. Which is then the attack vector vault prevents: saving permanent access tokens. Off the cuff that’s how I see it. I’m not actually in SRE or security so I’d welcome other opinions.

thequailman 7y ago

To me, this represents a fatal flaw in Vault's architecture. What it does should be table stakes/standardized and operate in a distributed fashion via integration into the underlying secrets engines. I'm honestly surprised the CNCF hasn't found a project out there to challenge Vault, we desperately need alternatives.

lstamour 7y ago

The real question might be if having it in one place makes monitoring and revocation easier than distributed trusted systems? Also, traditional passwords/secrets don’t expire, and if they do expire, how would you maintain trust in a distributed fashion outside of... complicated multi-part keys, something less secure like DNS, and/or more permanent tokens like the private keys used by a CA system? Somebody somewhere has to maintain a private or secret key, or you need a human to intervene. And even if you store the key on hardware, any users of the key could be compromised. I guess what I’m getting at is—there probably isn’t a perfect answer, just tradeoffs. And if history has taught us anything, it’s a case of “when” not “if” something is attacked/broken. If so, perhaps you should partition your data, including infrastructure, to not rely on just one Vault server for everything? Outside of that, or monitoring, the only other clear answer everyone leans on is “Store it in the cloud,” under the assumption that the hardware and people processes at cloud companies will be more secure overall than anything you’d develop. Which is then the attack vector vault prevents: saving permanent access tokens. Off the cuff that’s how I see it. I’m not actually in SRE or security so I’d welcome other opinions.