Vault admin policy

You’d think so, wouldn’t you? :slightly_smiling_face: But actually there is a caveat.

path "*" is very general, so has very low precedence, for picking between it and other paths in the resultant policy.

There are no other path blocks in this policy, but Vault merges all policies associated with the token and identity to come up with a resultant policy. Therefore:

Issue 1: If this policy is assigned along with other policies, those other policies may override this policy with lesser access for some paths.

Issue 2: (A special case of Issue 1) By default, Vault attaches the default policy to all tokens, unless specifically overridden. The default policy contains a selection of path blocks designed to enable basic Vault functionality. Many of these are not an issue for this use case, as they grant all of the access that is useful to have, for the path involved. One key exception though is:

# Allow a token to look up its own entity by id or name
path "identity/entity/id/{{identity.entity.id}}" {
  capabilities = ["read"]
}
path "identity/entity/name/{{identity.entity.name}}" {
  capabilities = ["read"]
}

which, in combination with your admin policy, overides the admin’s permissions on their own entity back to just "read".

Possible solutions are to explicitly grant full access to the individual paths overridden elsewhere, in your admin policy, or to make special settings in the relevant auth method so the admin has a way to log in without getting the default policy.

The solution of adding additional paths to the admin policy feels the least-worst option to me, as it doesn’t require the admin to log in in a different way.

1 Like