Policy for Nested Key Paths

I’m struggling to create a policy that allows users to access secrets stored in kv2 secret engine in nested paths.

  • example_kv a kv2 secret engine with nested secrets
  • example_kv/top is an example of a secret key with a value at the top level
  • example_kv/path/to/key is an example of a secret key with a value in a subpath

This suggested policy gives a blank page in the web ui:

path "secret/data/example_kv/*" {
  capabilities = ["create", "update", "list", "patch", "read", "delete"]
}

With this next policy, the web ui shows the example_kv secret engine and allows the user to see the first layer of paths example_kv/path in the secret engine but nothing further (example_kv/path/to... ):

path "example_kv/*" {
  capabilities = ["create", "update", "list", "patch", "read", "delete"]
}

Can someone help create a policy that applies to nested paths?

This policy assumes a KV v2 secrets engine mounted at secret/ containing secret paths within it that start with example_kv/.

Then something extra, not described here, is going on, as this policy does grant full access throughout all of the secrets engine at example_kv/.

It is critical when working with KV v2 to understand that all of its URLs include an extra path segment between the secrets engine mount point, and the secret path within it.

Therefore if your KV v2 secrets engine is mounted at example_kv/ and you are working with a secret within it at path/to/key, the URL-paths you will actually use will be:

  • example_kv/data/path/to/key - Implements create, update, read, delete, patch - used for most common operations EXCEPT list.
  • example_kv/metadata/path/to/key - Implements list, create, update, read, delete - used for list, modifying per-secret configuration settings, modifying per-secret custom metadata, and deleting the full version history of a secret.
  • example_kv/delete/path/to/key - Implements update capability only - soft delete of a single version of a secret.
  • example_kv/undelete/path/to/key - Implements update capability only - reverses soft delete of a single version of a secret.
  • example_kv/destroy/path/to/key - Implements update capability only - permanently wipes a single version of a secret.
  • example_kv/subkeys/path/to/key - Implements read capability only - returns JSON structure of secret with the values filtered out.

It is these URL-paths which would appear in your policies.

I suppose this is the issue I’m having. Though the policy is in place, the users are experiencing issues with the WebUI. Maybe it’s a bug in the UI and not a policy issue.

Unfortunately, the users rely on the WebUI for following their processes.

As a workaround, I’ve given users full access to the vault instance.