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.
so much fun with Vault. image source here

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.idThe entity's ID
  • identity.entity.nameThe entity's name
  • identity.entity.metadata.<metadata key>Metadata associated with the entity for the given key
  • identity.entity.aliases.<mount accessor>.idEntity alias ID for the given mount
  • identity.entity.aliases.<mount accessor>.nameEntity alias name for the given mount
  • identity.entity.aliases.<mount accessor>.metadata.<metadata key>Metadata associated with the alias for the given mount and metadata key
  • identity.entity.aliases.<mount accessor>.custom_metadata.<custom metadata key>Custom metadata associated with the entity alias
  • identity.groups.ids.<group id>.nameThe group name for the given group ID
  • identity.groups.names.<group name>.idThe group ID for the given group name
  • identity.groups.names.<group id>.metadata.<metadata key>Metadata associated with the group for the given key
  • identity.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
fair

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.

the MOUNT ACCESSOR value

Ooooh the sys/auth endpoint, right. Yeah, just smack a GET there and hope for the best.

oh

Apparently it was just so. Also we could’ve done the below for the same effect.

vault auth list
here they are

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

zooming in on the policy name for no reason

Then doing pass change should be allowed

vault write auth/userpass/users/testuser password=1234
seems fair

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.

assigning our magic policy to another user

By mistake I tried to modify our previous user’s password and it failed, which is nice,

noice

also the user could change their own as expected.

noicex2

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
how lovely

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.

MOUNT ACCESSOR

--

--

--

Let’s talk devops, automation and architectures, everyday, all day long. https://www.linkedin.com/in/yigitirez/

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Call me Disney: My first Animation in Unity.

Code comments? No comments

Build Functions In The Most MaintainableWay— clean code part 3

FAQs for Data Upload with MaxCompute Tunnel

GCP gcloud commands

Stack Overflow & InnerSource

Laravel Open Source projects

Simple Isn’t Easy — In Programming

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Yiğit İrez

Yiğit İrez

Let’s talk devops, automation and architectures, everyday, all day long. https://www.linkedin.com/in/yigitirez/

Vault Authorization — ACL(Access Control List) Policies

GitHub — vmware/kube-fluentd-operator: Auto-configuration of Fluentd daemon-set based on Kubernetes…

Installing boundary in minikube cluster with out default generated resources

GitOps with NSX Advanced Load Balancer and Jenkins