Policies specifying the same path but one with parameter constraints

Vault
1

A token with the following policies:

#Read entities
path "/identity/entity/id/*" {
  capabilities = ["read"]
}

#Update entities but require a name and metadata as well as deny giving it policies
path "/identity/entity/id/*" {
  capabilities = ["update"]
  
  required_parameters = ["name", "metadata"]
  
  denied_parameters = {
    "policies" = []
  }
}

will not be able to read entities using the read entities by ID API:

$ curl \
    --header "X-Vault-Token: $vault_token" \
    http://127.0.0.1:8200/v1/identity/entity/id/$entity_id
{"errors":["1 error occurred:\n\t* permission denied\n\n"]}

However, changing the update entities policy above to remove required_parameters and denied_parameters allows the previous request to succeed.

My suspicion is that the policies are essentially merging and thus making the read policy have the same parameter constraints as the update policy.

Is the result of the scenario expected? If so, how would I achieve this? I would have thought the given scenario is common.

2

Yes, that is indeed how Vault policy merging works. You are correct to point out that this makes it basically incompatible with the use of required_parameters.

I know of no public design documentation, but I my best guess is that this behaviour is not the result of design, but just emerged from required_parameters and policy merging being designed separately, interacting in an unhelpful way.

Unfortunately I suspect the only practical solution is to just not use required_parameters … or to pass dummy ignored parameters with the read call (http://127.0.0.1:8200/v1/identity/entity/id/$entity_id?name=ignored&metadata=ignored)