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.

image source here

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 db-admin and 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?

aliases, entities and groups and how they could be related in a use case

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.

an automatic entity

manual entity creation

After the creation of the Entity we need to add our User1 aliases.

adding an alias to the entity

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.

double check entity and alias names

After that you should be seeing added aliases to your entity. I just added one for testing purposes.

great

Now, try a login with the below command

vault login -method=userpass username=testuser

noice

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-ro and t1app-access-wr. We know how policies work now so no need to manage contents.

Yes, I am this lazy

assigned a policy

Now let’s attach testuser alias to this entity as well

Doing another login with testuser

well well well

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.

doing a bit of spring cleaning

group creation

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 default and 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 policies field.

the assignment of policies

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

enabled secrets engines

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.

this is the way (mostly)

Thanks for reading and see you next time.