Great writeup, although I'm confused how this fixes the problem of having a hard-coded string somewhere (file, ENV var, whatever) that contains the database credentials. Unless I'm mistaken, doesn't this solution just "move" the problem? It seems like you still need to keep a VAULT_TOKEN somewhere, just as you had the database credentials without vault?
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
Tokens 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.
Tokens give a massive increase in auditing, since they are unique to each authorized workload.
The tokens can be locked to a specific IP address.
Let me know if you'd like an example of this, Mike, since I can probably write a network state diagram from memory at this point!
Regardless, I'll have a separate post on this, later, since I've been asked this question by almost every smart security guy to whom I've presented Vault.
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
// , 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.
You would't have to handle DB credentials, instead the application will be requesting them via API. The trend is that the systems can be dynamically authenticated without human intervention.
In regards to the VAULT_TOKEN, Vault support some some other authentication backends, but having the VAULT_TOKEN doesn't give you access to the DB.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great writeup, although I'm confused how this fixes the problem of having a hard-coded string somewhere (file, ENV var, whatever) that contains the database credentials. Unless I'm mistaken, doesn't this solution just "move" the problem? It seems like you still need to keep a VAULT_TOKEN somewhere, just as you had the database credentials without vault?
// , Other advantages which Francisco did not mention are that "moving" the problem in this way
Tokens 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.
Tokens give a massive increase in auditing, since they are unique to each authorized workload.
The tokens can be locked to a specific IP address.
Let me know if you'd like an example of this, Mike, since I can probably write a network state diagram from memory at this point!
Regardless, I'll have a separate post on this, later, since I've been asked this question by almost every smart security guy to whom I've presented Vault.
Update: Later, the separate post is here dev.to/v6/the-first-smart-question...
// , 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.
You would't have to handle DB credentials, instead the application will be requesting them via API. The trend is that the systems can be dynamically authenticated without human intervention.
In regards to the VAULT_TOKEN, Vault support some some other authentication backends, but having the VAULT_TOKEN doesn't give you access to the DB.