Vault Part 8 - Vault Authorization: Policy Path Templating
Goal: This post aims to provide a brief look into Vault policy path templating as part of a series of posts starting from here.
What we need
- Running Vault, preferably in dev mode. See Part 1 for installation if it doesn’t exist.
Policy Path Templating
“So, why is this not in the policy article” is a superb question and the answer is I was doing my best to ignore templating until I couldn’t. Seems most use cases can be worked around with some ugly legwork and no proper debug for these is just asking for trouble (If you know of a way, do link something so I can read up on it, thanks).
In short, we can make use of dynamic data on our policy path permissions. Below is the list of data we can use. Source.
identity.entity.id
The entity's IDidentity.entity.name
The entity's nameidentity.entity.metadata.<metadata key>
Metadata associated with the entity for the given keyidentity.entity.aliases.<mount accessor>.id
Entity alias ID for the given mountidentity.entity.aliases.<mount accessor>.name
Entity alias name for the given mountidentity.entity.aliases.<mount accessor>.metadata.<metadata key>
Metadata associated with the alias for the given mount and metadata keyidentity.entity.aliases.<mount accessor>.custom_metadata.<custom metadata key>
Custom metadata associated with the entity aliasidentity.groups.ids.<group id>.name
The group name for the given group IDidentity.groups.names.<group name>.id
The group ID for the given group nameidentity.groups.names.<group id>.metadata.<metadata key>
Metadata associated with the group for the given keyidentity.groups.names.<group name>.metadata.<metadata key>
Metadata associated with the group for the given key
Going by the examples and trying to make sense of them, the user/pass password change sounds sensible. Let’s try that out. Doing a quick run of changing password for our testuser
VAULT_TOKEN=s...w vault write auth/userpass/users/testuser password=1234
Let’s now create our MAGIC policy. Checking the example we got below
path "auth/userpass/users/{{identity.entity.aliases.auth_userpass_6671d643.name}}" {
capabilities = [ "update" ]
allowed_parameters = {
"password" = []
}
}
But where is the magic number describe as <mount accessor>
auth_userpass_6671d643 coming from? Why, the docs are very clear at this point.
Ooooh the sys/auth
endpoint, right. Yeah, just smack a GET there and hope for the best.
Apparently it was just so. Also we could’ve done the below for the same effect.
vault auth list
Let’s update our magic policy to include our MOUNT ACCESSOR (sounds impressive) for userpass and attach that to either entity, group or user itself to test it out.
First we should be seeing our new policy after login
Then doing pass change should be allowed
vault write auth/userpass/users/testuser password=1234
I’m not convinced yet though. Let’s attach this policy to another user to try it out. I have a user that can do nothing except this operation. Curious to see how that plays out.
By mistake I tried to modify our previous user’s password and it failed, which is nice,
also the user could change their own as expected.
So the other actively used <group id>
and <group name>
accessors for path templating can be reached via the below commands.
vault list identity/group/id
vault list identity/group/name
I really like that you could either get the id or the name of the group but not both at the same time. Who would need both at the same time right?/s You can read more here.
To summarize templating, you could do whatever magic you preferred with whatever MOUNT ACCESSOR or groups you desired. I have not yet come across a use case for it but will create another story just for that if it pops up.
That’s all for this story. Thanks for reading and see you next time. Also can’t resist the urge to type MOUNT ACCESSOR one last time.