0

HashiCorp Vault is an open source tool for secrets management.

I'm using it for this purpose, and have come across a minor issue. I seemingly cannot deny access to a specific API path.

I've tested this on 2 different Vault clusters. And it seems like I can't deny access to the "sys/leases/lookup" path.

Do "deny" capabilities trump the parts of policies that give explicit capabilities on a path?

It seems that that's not the case, since the capabilities from the default policy are being favored over those in my "deny-leases" policy.

The default policy allows lease lookup: 

# Allow looking up lease properties. This requires knowing the lease ID ahead
# of time and does not divulge any sensitive information.
path "sys/leases/lookup" {
    capabilities = ["update"]
}

And my creatively named "deny-leases" policy, well, you might say that it doesn't allow lease lookup: 

~ |  vault policy read deny-leases 
path "sys/leases*" { 
 capabilities = ["deny"] 
 }

Let's make 'em fight! 

~ |  vault token create -policy=deny-leases
Key Value
--- -----
token s.10yrKnAdsBaxTErxXxXvAuLt
token_accessor 2c8beef0kPVLuSjtSsStONgs
token_duration 768h
token_renewable true
token_policies ["default" "deny-leases"]
identity_policies []
policies ["default" "deny-leases"]
~ |  export VAULT_TOKEN=s.10yrKnAdsBaxTErxXxXvAuLt
~ |  curl --silent --header "X-Vault-Token: ${VAULT_TOKEN}" --data '{"lease_id": "auth/userpass/login/heyitsme/deadbeefdeadbeef85cbd6edf586527d824e09560987654321123817e96234e93"}' --request PUT "${VAULT_ADDR}/v1/sys/leases/lookup" | jq 
{ 
 "request_id": "f98e2444-357b-bcof-feef-74b58443feef", 
 "lease_id": "", 
 "renewable": false, 
 "lease_duration": 0, 
 "data": { 
 "expire_time": "2019-01-21T17:03:41.72395079-05:00", 
 "id": "auth/userpass/login/heyitsme/deadbeefdeadbeef85cbd6edf586527d824e09560987654321123817e96234e93", 
 "issue_time": "2018-12-20T17:03:41.72395019-05:00", 
 "last_renewal": null, 
 "renewable": true, 
 "ttl": 1049229 
 }, 
 "wrap_info": null, 
 "warnings": null, 
 "auth": null 
} 
~ |

Looks like the default policy "wins", here, because its explicit allowing of that capability overrode the explicit denial in the deny-leases policy.

How does Vault decide which policy "wins", and how would I restrict access to the lease lookup?

Nathan Basanese
  • 640
  • 1
  • 9
  • 20
  • // , Details are anonymized to protect the guilty. – Nathan Basanese Jan 09 '19 at 19:08
  • 1
    This question seems very specific to how Hashicorp Vault was implemented. Would it be more productive to go diving in Vault documentation, and open a service ticket with Hashicorp if it's not described? – Mike Ounsworth Jan 18 '19 at 03:54
  • // , Jeff sent me the answer. If one policy has a *, and another doesn't, the one without the * will be honored as being more "specific", as in the yellow warning box here: https://www.vaultproject.io/docs/concepts/policies.html#policy-syntax I had somehow expected that a `deny` capability would override this, given Vault's design principle of default deny. I'll add my own answer once the heat's died down. – Nathan Basanese Jan 18 '19 at 04:00
  • // , And I'd say it's also a matter of design, rather than just implementation. – Nathan Basanese Jan 18 '19 at 04:01

1 Answers1

0

The short, and unsatisfying partial answer, here, is to just modify the default policy to remove or "comment-out" (I know) the sys/leases/lookup stanza. 

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

Still doesn't answer the broader question of the nitty gritty details of how one set of Policies' deny capabilities might or might not override capabilities allowed in another Policy, and where.

forest
  • 64,616
  • 20
  • 206
  • 257
Nathan Basanese
  • 640
  • 1
  • 9
  • 20
  • // , Update: `deny` will only override other capabilities if the `deny` capability is on an equally specific path or a MORE specific path than the other capabilities. – Nathan Basanese Oct 28 '20 at 07:18