Vault Part 7 - Vault Authorization: Aliases, Entities and Groups
In part 1 of Vault Authorization we focused on policies and how they worked. Now, we hand out these policies with as much grace as we can muster.
Aliases, Entities and Groups are Vault’s way of grouping access control. Everyone starts with an Alias and an Entity, which Vault will create if it doesn’t exist, as soon as they login to Vault. A single user with accounts in multiple authentication methods will have multiple Aliases as well. In the below example, User1 has both user-pass and aws login accounts defined in Vault. We can assign policies
poly individually for both accounts. In the case of overlap though, we would be creating redundant policies tailored to each case individually. What if something changed?
Instead, like the above image suggests, we can make use of Entities to group aliases and assign a base policy to it. Let’s merge all User1 aliases to a User1 entity.
After the creation of the Entity we need to add our
You can double check list of aliases like below since UI does not have a confirmation of if you wrote it correct or not so need to double check auth backend end name for typos.
After that you should be seeing added aliases to your entity. I just added one for testing purposes.
Now, try a login with the below command
vault login -method=userpass username=testuser
We can now see the main entity policies as well when we login with any attached alias.
One thing I was curious about was that while it’s great that user1 allowed grouping of core policy permissions for that specific user but what if I wanted further control. Perhaps allow t1 app secrets access? Can I stack aliases on different Entities. Let’s create a
t1app-access entity and create two exact policies named
t1app-access-wr. We know how policies work now so no need to manage contents.
Now let’s attach
testuser alias to this entity as well
Doing another login with
Now that’s something to think about. base-dev disappeared without any information to the user. You apparently cannot attach the same alias to multiple entities. For that they want us to make use of Identity Groups which can contain multiple entities or groups. So
t1app-access does not need to be an entity. Let’s make it a group.
First we should delete the entity
t1app-access and create a group with the same name.
Notice that entities are selectable, thankfully, unlike aliases so let’s select user1. Doing a login afterwards notice that we still have the base-dev policy coming from the user1 entity. Also interesting is the way the information is displayed. So we have our alias policies
dbadmin and then the policies coming from entities and groups listed in
identity_policies. The whole list of available policies of our token is in
This magic is possible with the use of identity secrets engine that’s “hidden” (from the UI). You can see it with the secrets list command as root.
vault secrets list
It’s mounted by default and cannot be moved. More info on that, here.
Also as a side note, remember below field during groups setup. Internal means Vault created groups and External means group names & members will be pulled from an outside source. We will leave this for another run.
Thanks for reading and see you next time.