Sudo Permissions when creating vault policies

Vault
1

I am new to the vault and trying to understand “sudo” permissions a little better. I know it is used for Root protected API endpoints. Is there a way to find all the root protected API endpoints.

Why does sys/leases/* with sudo permissions not return a list of lease ids but instead gives a permission denied error when calling “list /sys/leases/lookup/” but when I add the path “sys/leases/lookup” with sudo permission it works. Below are my path definitions:

path “sys/leases/*” {
capabilities = [“create”, “read”, “update”, “delete”, “list”, “sudo”]
}

path “sys/leases/lookup” {
capabilities = [“list”, “sudo”]
}

2

The full list of root protected endpoints in 1.12.2+ent is:

auth/token/accessors/
pki/root
pki/root/sign-self-issued
sys/audit
sys/audit/{path}
sys/auth/{path}
sys/auth/{path}/tune
sys/config/auditing/request-headers
sys/config/auditing/request-headers/{header}
sys/config/cors
sys/config/ui/headers/
sys/config/ui/headers/{header}
sys/leases
sys/leases/lookup/
sys/leases/lookup/{prefix}
sys/leases/revoke-force/{prefix}
sys/leases/revoke-prefix/{prefix}
sys/plugins/catalog/{name}
sys/plugins/catalog/{type}
sys/plugins/catalog/{type}/{name}
sys/raw
sys/raw/{path}
sys/remount
sys/replication/dr/primary/secondary-token
sys/replication/performance/primary/secondary-token
sys/replication/primary/secondary-token
sys/replication/reindex
sys/revoke-force/{prefix}
sys/revoke-prefix/{prefix}
sys/rotate
sys/storage/raft/snapshot-auto/config/
sys/storage/raft/snapshot-auto/config/{name}

I obtained this by retrieving the OpenAPI document from sys/internal/specs/openapi and parsing the result to find all the paths where x-vault-sudo is specified.

They are one of the more confusing, and poorly documented parts of Vault.

First, they have very little at all to do with the classic Linux/Unix sudo command - there is no sense of “step-up” authentication or change of identity.

The real function of Vault’s sudo capability is to force the author of an ACL policy to make it explicit that they truly do mean to unlock access to an unusually privileged endpoint, and not, for example, accidentally grant such access, possibly via a wildcard path match.

Even then, the choice of which paths are root protected and which ones are not, feels a bit arbitrary to me - certainly nowhere in the documentation have I been able to find an explanation of the general decision-making process that drives whether paths are made root-protected.

If you’re looking at just those two path blocks on their own, the second one is indeed redundant, as you wondered. However, the default Vault policy includes this path block:

path "sys/leases/lookup" {
    capabilities = ["update"]
}

So, if you only use the sys/leases/* block from your code, then after policy merging of all policies applying to your session, the most specific match for sys/leases/lookup is the update-only block from the default policy.

Hence, you need to specifically re-add the list and sudo capabilities to that path.

This is one of the annoying weird corner cases that arises from Vault policy merging - I don’t really like how the policy language behaves in this way.

3

Than you! Your explanation of “sudo” privileges helped a lot. I was also able to get the list of all the root protected API endpoints from sys/internal/specs/openapi as you described.