When I'm setting up HashiCorp Vault for different internal customers, I have to explain what the hell Vault is. That usually goes pretty well. "Lastpass, but for use by Infrastructure and Server software instead of humans?" "Makes sense."
But then, I have to explain how Vault works.
"So now, instead of having a plaintext credential in source code or configuration files, you can make your software authenticate to Vault to get the credential... tokens... and now I'll pause for a bit to see what you think about all this."
I pause for questions, and give people time to think. And there's always that guy, the one with the questions.
Let's call this Architect "Mistrustful Max".
"Aren't we just moving the problem?
I mean, I know that don't have to put DB credentials in a plaintext.propertiesfile, and can generate them dynamically from Vault instead.
But I now have to store a Vault Token in plaintext, and anyone who gets the Vault Token can just generate the DB credentials from the Vault!
What's the point of Vault if it's just the same vulnerability with extra steps?"
It's gotten to the point that I can walk into a meeting and tell who it's going to be, even before he asks. Call it instinct.
Here's a very high level diagram of Vault's Token authentication
Anyway, after a bit of white boarding and a high level demo of Vault's Token authentication, other specialists and architects are often justifiably skeptical how Vault Tokens fix the problem of having a hard-coded string somewhere (file, ENV var, whatever) that contains the credentials themselves.
He'll point out that it looks suspiciously like "moving" the security challenge, because it seems like he still has to keep a VAULT_TOKEN somewhere, just as he had to do with the credentials without Vault.
Mistrustful Max's right!
Vault does move the problem. But that's because there are advantages of "moving" the problem in this way, and (Token != Password):
InfoSec now has visibility, and one place to protect/ACL secrets, because the problem is being moved to a central location they know about. It's an improvement over the usual 1000 places, only half of which InfoSec might know about.
Tokens are always temporary, and are only obtained by an application which has non-token credentials. These credentials can be configured to your taste, and have varying degrees of non-repudiation protection, e.g. from IP address locking up to a combination of signed instance metadata and client certificates.
Because the tokens are not present in the source code, and only obtained when the workload starts, they never have to be stored on disk or in source code, removing the "hard-coded" problem.
Only one place where you have to update the password, instead of everywhere that it's present in code and configuration. This is as opposed to some one changing a password out of band, causes some other app (using that password) to fail.
Tokens give a massive increase in auditing, since they are unique to each authorized workload.
Revoke a Vault Token for a specific instance (webserver) without affecting other running instances or changing underlying password
The tokens can be locked to a specific IP address, subjected to a much shorter automatic expiration period than the original pass phrase, stored only in locked memory with something like anjuna or mlock(), delivery-wrapped, and with only a specific number of uses allowed.
Tokens are the starting point for closer integrations like Consul-template
The metaphor I like to use for Vault Tokens is a session token for web applications.
While the token itself may not be all that special, security-wise, a user can only get the Vault Token by doing whichever song and dance you've set up for login.
And that token is time-limited, auditable, tied to a specific range of IP addresses, and specific to each client.
Anyway, now when I get asked this question, I have a page I can point to.
Article Shortlink: https://v.gd/Ri6ITH
Top comments (0)