Docs: prefix in path for /sys/leases/revoke undocumented

[wernerb]

Describe the bug
The sys/leases page documents the /sys/leases/revoke api endpoint to revoke using a payload.json with the lease id in there. (https://github.com/hashicorp/vault/blob/master/website/source/api/system/leases.html.md)

The cli makes use of a variant of the above where the the lease_id is specified as a prefix:
/sys/leases/revoke/<:prefix>. This is undocumented and should be specified in the docs.

This allows us to use policies to lock down users to revoke specific lease paths.

# allow 
path "aws/creds/myawsrole" {
  capabilities = ["read", "update"]
}
#allow revoke
path "sys/leases/revoke/creds/myawsrole/*" {
  capabilities = ["update"]
}

To Reproduce
Steps to reproduce the behavior:

1. Create policy as above and secret backend. Create token with policy as above.
2. Run vault lease revoke -sync aws/creds/myawsrole/S6LVj3OMGsSqGwNVUYSI2agf
3. Notice that the token is allowed to revoke lease.
4. Use the documented api and use payload.json to supply lease_id.
5. Notice that you get a permission denied as policies only work on paths, which is apparently what the vault cli uses.

Expected behavior
Add <:lease_id> to documentation for the /sys/leases/revoke command as optional to make clear it can be used.

Environment:
Vault v1.0.3

[jefferai]

Hi Werner,

What you're seeing is legacy/deprecated functionality that is there to keep (at this point, very) old workflows working. Putting lease IDs in paths is not generally considered a good idea since lease IDs are at least sensitive (e.g. sharing them could allow someone else to revoke your lease). That's why we've only documented the recommended approach. (We realize that if the intent is to revoke it it doesn't really matter, but the revocation could fail (leaving you with a now-logged lease ID) and as a matter of best practice we wanted the paradigm to be the same across renew/lookup/revoke.)

If you want to allow path-based revocation, use the revoke-prefix endpoint (https://www.vaultproject.io/api/system/leases.html#revoke-prefix) which codifies this behavior. It is possible for that prefix to be scoped all the way to a single lease ID if you really want.

[wernerb]

@jefferai Ah this makes sense. It is weird though that the deprecated method is actively used in the CLI.
Just to confirm then. there is no way for people to use policies to lock down a specific prefix without sudo rights, and this is the intended use-case?

The reason i'm asking is that the spring-vault library currently does a revoke on KILL signal on all its leases. It uses the non-path-based revoke api. There is now no way for me to lock down rights for this user to revoke only what belongs to themselves.

Do you have advice on what the downstream library should do? 1. Move to revoke-prefix? 2. don't revoke at all, just set max-ttl and expect leases to be cleaned up

As you can understand the situation with the spring-vault library is untenable as in its current form to not get errors all applications should be able to revoke all paths which for us is a security problem.

[ThomasKasene]

@jefferai I'd like some clarification on Werner's questions too, please :)

Do you have advice on what the downstream library should do? 1. Move to revoke-prefix? 2. don't revoke at all, just set max-ttl and expect leases to be cleaned up.

I'm struggling with the same issues with Spring Cloud Vault, and from my point of view, option 1 seems like the best one, but is revoke-prefix a solution Hashicorp wants 3rd party libraries to use?

[bendem]

In case it helps anybody, since this is a top search result and is unanswered, the fix for this is to restrict your policy using allowed_parameters. We do this for our spring boot applications (this is a jinja template, you have to adapt it for your use case). We also force sync to true to catch revocation errors.

path "database_pg_{{ env }}/creds/{{ database_name }}-{{ pg_role }}" {
  capabilities = ["read"]
}

path "sys/leases/revoke" {
  capabilities = ["update"]
  allowed_parameters = {
    lease_id = ["database_pg_{{ env }}/creds/{{ database_name }}-{{ pg_role_type }}/*"]
    sync = ["true", true]
  }
  required_parameters = ["sync"]
}