Vault: Dynamic Policies

[enudler]

Would it be possible to implement dynamic policies which path depends on the policy name
The motivation is to have multiple policies (per user for example)
But instead of creating specific policy for a user, create only one.
It could be something like:

{
"type": "dynamic",
  "name": "policy_{}",
  "rules": "\npath \"secret/creditCards/policy_{}/*\" {\n    capabilities = [\"read\"]\n}"
}

When creating token with policy: policy_1234
It will have read access to secret/creditCards/policy_1234 and so on..

[jefferai]

This is something we've discussed internally but it is not currently on the roadmap as I think to implement this properly there are some prerequisites, like a better understanding of identity.

[shomron]

We've implemented a policy compilation toolchain internally which supports this functionality. An external file defines your dimension values, and then template policies can reference them. At compilation time, a policy will be blown out according to these. We also extended the policy HCL syntax to allow defining the policy name inside the file.

Example:

dimensions.yml:

tier:
  - dev
  - stage
  - prod

policy-template.hcl:

id = "policy-{{tier}}"

path "secret/namespace/appname/{{tier}}/secretstuff" {
  policy = "read"
}

The policy will be loaded 3 times, one for each value of the dimension value.
We also support multiple dimensions and load the cartesian product of those.

[frntn]

@jefferai any plan to add this to the roadmap ?

My use case would be like this one :
_(maybe you can think of a workaround somehow...)_

1. I have a ldap cluster
2. Users authenticate to vault using the ldap auth backend
3. Users can write in their own namespace (eg. secret/user/<dn>/*)

Vault likes to state it is filesystem-like.
We may now need unix-like homes :smile:

[jefferai]

No plans at the moment, sorry.

[mapa3m]

+1, this would be an extremely useful feature for us as well, our setup is exactly as described by @frntn above

[Krijger]

I was trying to found out how to achieve exactly what @frntn described above as well. If anyone has insights how to apply dynamic policies, I would be interested.

If a policy could have a variable in a path, that would be awesome.

[mflococodev]

Really could use this feature. Our organization has hundreds of thousands of users - dynamic policies are a must.

[Larchy]

+1 - Really useful for Employee Credential Storage mechanisms

[joelthompson]

For those who hadn't heard, at HashiConf, they announced a new policy language, Sentinel, for the paid versions of Vault. I haven't yet had a chance to play around with Sentinel in depth, but from what I've seen and read in the docs, it seems like it is designed for precisely this use case, and I'd suggest people check it out.

Note: I'm not a HashiCorp employee and so I'm not trying to sell anybody the paid version of the software; I just thought the followers on this thread would be interested in hearing about Sentinel (if they hadn't already), and I of course can't speak to the roadmap for Vault (either OSS or paid editions).

[jefferai]

In addition to what @joelthompson said above, for 0.11 (unless it slips) we have some plans to add some templating to the ACL language which will help with many of these cases. Since that's on our roadmap I'm going to close this for now.

[frntn]

Thanks @jefferai
Is there a roadmap page somewhere to refer to ?

[tmszdmsk]

I believe it is materialized in this PR: https://github.com/hashicorp/vault/pull/4994

[sleepylee]

great added feature, docs can be found here https://www.vaultproject.io/docs/concepts/policies.html#templated-policies

[frntn]

Definitely need to try this out !
Even 18 months after I needed it 👼

[jefferai]

We needed Identity built up :-D

[perj]

I'm not sure if this is a good place to comment now but it's very unclear to me what the "identity" is on that page.

[lrstanley]

@perj I think these would both help:

• https://www.vaultproject.io/guides/identity/identity.html
• https://www.vaultproject.io/docs/secrets/identity/index.html

Essentially the entity of however the user authenticated. I.e. when authenticating with LDAP, the username itself is part of the entity (if I think I know how it works.. hah), and that can be used in conjunction with these dynamic policies.

[AlKapkone]

@frntn
Hello, Matthieu
Did you manage to do this?

[AlKapkone]

@lrstanley
Hi, Liam
What about you? Did you manage to do this?

[AlKapkone]

If enyone is interested, i give an instruction that helped me to create dynamic policy template for LDAP in my case.
First of all add LDAP auth method and copy it's _mount accessor_ (like this auth_ldap_1c83b028).
Then create new policy:

vault write sys/policy/template policy='
path "secret/_your_company_/{{identity.entity.aliases.auth_ldap_1c83b028.name}}/*" {
capabilities = ["create", "update", "read", "delete", "list"]
}

this is needed to use when working with Vault UI

path "secret/" {
capabilities = ["read", "list"]
}
path "secret/_your_company_/" {
capabilities = ["read", "list"]
}'

vault write auth/ldap/users/_YOUR_LDAP_USER_ policies=template
vault login -method=ldap username=_YOUR_LDAP_USER_

so you can attach this template policy to everyone LDAP user from your company and users can write in their own namespace (eg. secret/_your_company_/_YOUR_LDAP_USER_/*).

[sakof]

@AlKapkone: I have been trying all day to use templated ACL.
So far I had it to work with the entity_id but it seems that using identity.entity.aliases.myauthaccessor.name does not work for me (using 0.11).
Also, being fairly new to vault this might sound dumb, but to use mount accessor id, shoudn't I be able to list my ldap auth provider in sys/mounts? Because on my setup it's definitely not there.

Your instruction is exactly what I'm trying to achieve but for some reason, this specific variable doesn't seem to be usable in my ACL.

[AlKapkone]

@sakof
$ vault auth enable ldap
$ vault auth list
Path ............ Type ............Accessor .........................Description
alicloud/ ......alicloud .......auth_alicloud_95d62a03 n/a
ldap/ ...........ldap .............auth_ldap_1c83b028 n/a

You shoudn't be able to list your ldap auth provider in sys/mounts (because ldap is an auth method, but command vault secrets list lists the enabled secrets engines on the Vault server).

[AlKapkone]

@sakof Have you configured connection to your LDAP server like in this instruction ?
https://www.vaultproject.io/docs/auth/ldap.html
What does show you output of next command ?
$ vault read auth/ldap/config