If the first wildcard ( + ) or glob ( * ) occurs earlier in P1 , P1 is lower priority
If P1 ends in * and P2 doesn’t, P1 is lower priority
If P1 has more + (wildcard) segments, P1 is lower priority
If P1 is shorter, it is lower priority
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.
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
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.
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: