// , “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.
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.
// , 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.