Hello,
I’m just reading on vault identities, and how you can leverage third party auth solutions to get access to secrets.
The case I’m trying to implement requires each one of my service users to have RSA keypair, which they use to encrypt/decrypt data. Are the vault identities valid usecase here? So I would authenticate my users to vault, and create storage for each of my service users and store RSA keypair there, so only if they authenticate with any of third party providers, they can access their keypair that is then used to do all kinds of things.
FYI there might be tens of thousands of users, is this still valid use case? Or are vault identities meant more for employee secrets?
If this is not a good use case, what should I do? If i require users to enter username & password, I can just encrypt the RSA keypair with users password and safely store it that way, but I won’t be able to use any third-party auth providers, as they return access token and they don’t return any unique secret that could be used to encrypt the keypair.
Thanks!
Vault’s Identity secrets engine is leveraged whether or not you explicitly configure anything as it relates to your auth roles. Whenever an authenticated entity logs-in a Vault Identity Entity and Alias will automatically be created, unless you pre-create them ahead of time. So to address your question about whether these are for human vs. machine profiles - they’re for both.
As with many tools there are multiple ways to accomplish your goal, you’ll just need to figure out which method makes the most sense for you.
With Identity Entities and Groups (or the associated Aliases) you can assign metadata to each object in Vault and use policy templating to grant access to secrets with paths based on metadata contents. See the Policy Templating docs for more info on this.
You may find that leveraging simpler techniques may work just as well as pre-created Identity Entities and Groups, although I think you’ll still be using templated policies regardless, unless you want to create a policy per user/secret combination. In this case you could create a templated policy based on the username to grant access to a particular secret.
However, if the secret to be accessed differs based on how a particular user logs-in, then I think Identity Group/Entity Alias metadata based templated policy is probably the method to pursue here.