Policy list parent dir but not read

Vault
1

Hello, I am trying to create a policy which allows to list parent dir but not read it, but it does not work. Imagine I need list access to company/ but read and list access to /company/project. How should I do that?
for example following gives list access but cant read things under company/project

path "company/*" {  
  capabilities = ["list"]
}
path "company/project/*" {
  capabilities = ["list","read"]
}
2

company/* will allow you to list the company folder and anything within it. You’d probably want to remove the * to only allow listing of the company folder; assuming this is a KVv1 mount.

Is “company” a KVv1 mount, a KVv2 mount, a namespace, or something else? Depending on what type of mount it is the guidance may vary.

Please provide some additional context and we can better assist.

3

it is KVv2, tried without * too, also tried +, none helped. LIke it lists but second rule like overwritten I only can list second rule but not read

4

The documentation is not very good at explaining this, but KVv2 makes a distinction between “logical KV path” and URL path.

“Logical KV path” is a term I just made up for the sake of having a way to talk about it here, by the way.

In your example, company/ appears to be your KVv2 mount point, and project/ a “logical KV path” which you want to create some entries.

When you work with tooling that is specifically aware it is working with a KVv2 - like the Vault web UI, or the vault kv ... family of CLI commands, that’s all you need to know.

But, when you work with URLs, such as when you write policies, or use generic CLI commands like vault read ... (or write, delete, list) you need to know about the URLs used in the API, which insert another path component between the mount point and “logical KV path”!

<mount point>/<KVv2-operation>/<logical KV path>

The KVv2-operations, listed with the capabilities (in the ACL policy sense) that you can use with them are:

  • metadata (read list create update delete patch)
  • data (read create update delete patch)
  • delete (update)
  • undelete (update)
  • destroy (update)
  • subkeys (read) - new in Vault 1.10

Armed with this overall structure, grouping things into URLs, it should get slightly easier to cope with understanding the large number of operations detailed on KV - Secrets Engines - HTTP API | Vault by HashiCorp

An example, to wrap things up:

Suppose I do vault kv list company - the request sent to Vault is actually a list on company/metadata/

and if I do vault kv put company/project/example x=y the request sent to Vault is actually a create or update on company/data/project/example

1 Like
5

Thank you for such detailed explanation, basicly it means I have to use below policy and do not have other choice? or there is way/policy to accomplish what I am looking for?

path "company/*" {  
  capabilities = ["list","read"]
}
6

No, it’s totally possible to do what you want, it just gets frustratingly verbose…

path "company/metadata/" {  
  capabilities = ["list"]
}

path "company/metadata/project/*" {  
  capabilities = ["list","read"]
}

path "company/data/project/*" {  
  capabilities = ["read"]
}
1 Like
7

worked like a charm, thank you very much.