4 ms·
My understanding of vault is not ironclad, but from what I have read it seems it allows ephemeral passwords that allow your application to get access to a servi
by aerovistae 8y ago
My understanding of vault is not ironclad, but from what I have read it seems it allows ephemeral passwords that allow your application to get access to a service at time of initialization, and then the password ceases to be valid. Which means your application has access, but there's no credentials floating around anywhere that they could be compromised later.
If anyone could correct me if I'm wrong, that would be great.
- no_one_ever 8y agoYou've more or less got it. You authorize to the vault and store the secrets in memory. So no passwords on-disk/in-source 'floating around'.
- xhrpost 8y agoBut how do you authorize to the vault then? Aren't there credentials for that part?
- ReidZB 8y agoYes, there is the "initial secret" problem. There are a variety of different ways Vault handles that (look up the auth plugin docs), but at my org we use AWS IAM auth. So, app servers authenticate via their IAM instance profile (provided/managed by AWS) while developers assume a specific IAM role and then authenticate via that (which is how we enforce MFA for Vault without paying the crazy enterprise pricing). Note that with AWS IAM auth, AWS is a trusted third party, and accounts with high-powered IAM access (think AWS admins) end up having a great deal of authority in Vault, too. But for us, at least, these assumptions are reasonable.
- sethvargo 8y agoThat's one piece of the functionality, but there's quite a few more. It's a pluggable system that can also generate more than "passwords" (like cloud IAM credentials, database credentials, PKI)