Vault policy docs on precedence/priority

The vault policy docs provide the below.

  1. If the first wildcard ( + ) or glob ( * ) occurs earlier in P1 , P1 is lower priority
  2. If P1 ends in * and P2 doesn’t, P1 is lower priority
  3. If P1 has more + (wildcard) segments, P1 is lower priority
  4. If P1 is shorter, it is lower priority
  5. If P1 is smaller lexicographically, it is lower priority

I feel a bit silly asking but can anyone provide an example where rule 5 would come into play? My understanding at this point is that it’s just capitalization, e.g. secret/FOO is lower priority than secret/foo.

secrets/foo/secretentry
secrets/foo/SecretEntry

secret* wins.

1 Like

Yep cool, as I thought then. Thanks for confirming :smiley:

Hope you don’t mind my using this question to better understand the least-priv justification #3 provides in the following example. The title is too perfect a match :slight_smile:

P1 = "secret/*"
P2 = "secret/+/+/foo/bar"

Similar to the example P1 and P2 in that doc page but with higher specificity with P2.

According to policy application order, P1 and P2 remain equal until #3, in which case P2 becomes lower bc of its multiple wildcard segments.
But P2 has a higher specificity that P1 and so this case doesn’t seem to adhere to least-priv principle. Hope someone can clarify this for me?

I don’t think there is a justification, or not a good one. As you’ve spotted, the rules result in a different prioritization to what any reasonable human would interpret as being more/less specific, and this has been a recurring source of confusion resulting in unexpected policy behaviour at my workplace.

1 Like

To clear up an incorrect understanding earlier in the thread…

No, Vault paths are case sensitive so these are just two different paths that could never both match the same request.

An example of path patterns that could both match the same request and would need rule 5 to define which won, would be:

  • kv/+/foo/+
  • kv/+/+/foo
1 Like

I concur with this.

I came up with the examples:

alpha/+/bravo/+/charlie
alpha/+/+/bravo/charlie

to e.g. match the path:
alpha/bravo/bravo/bravo/charlie

I did a quick test on a dev mode server, and indeed the lexicographically “bigger” “alpha/+/bravo/+/charlie” is the rule that applies!
(I even changed to order of the stanzas in the policy, and tried with different capabilities, to control for parse order and such.)

In my opinions this is a less-weighty version of rule #1: the earlier occurrence of a wildcard, the less priority!

Shameless plug: I am developing a wee tool to help people visualise Vault policies. It’s still in early development, but feedbakc is always welcome:

https://vaultpolicies.dev

Blockquote