Hacker News Reader

Comment by aerovistae | Hacker News Reader

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.

View on HN

You'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'.

But how do you authorize to the vault then? Aren't there credentials for that part?

Yes, 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.

That'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)

Reply on news.ycombinator.com