Entity_alias and token create

one of the options when creating a token is using a role and specifying an entity_alias

entity_alias (string: "") > - Name of the entity alias to associate with during token creation. Only works in >combination with role_name argument and used entity alias must be listed in ?>allowed_entity_aliases . If this has been specified, the entity will not be inherited from the >parent.

is the entity_alias “name” unique across all entities and aliases ? If not, what is the name ?

Another question I have is regarding policies. If I use entity_alias on the token, I would expect to see the entity + group policies of that entity being used . Is this the case ? I seem to be getting the parent token policies

This is quite old, but I had the same questions. In case anyone comes across this…

I do think the documentation is a bit less than clear here.

I assumed that this could be any alias across all mounts to which the token could be linked. But looking at the code in token_store.go starting with the comment // Verify the entity alias it is clear that the alias must be in the same mount as the token request. The name must be unique within that mount accessor, and if it doesn’t exist it will be created. Thinking about it this makes sense, but I didn’t realize it from the documents alone.

I found that if you don’t specify policies at token creation and there are no allowed_policies associated with the role, then the token takes on the policies of the creating token (even if the role specifies an orphan token). However, if either allowed_policies exist or you specify policies at token creation the token gets those. In all cases I found the token also gets any policies associated with the entity or group. If you want those to be the only policies (i.e. if you were thinking of not specifying policies for the token and using only the entity and group ones) you can specify default as the token policy which will prevent it from picking up the parent token policies and leave it with only the entity/group ones. Presumably you could create an even less permissive policy than default to serve this purpose, but I haven’t tried that.

All of this is on Vault 1.6.1.

1 Like