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?

Improve this question
4
  • // , Details are anonymized to protect the guilty. Commented Jan 9, 2019 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? Commented Jan 18, 2019 at 3: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: 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. Commented Jan 18, 2019 at 4:00
  • // , And I'd say it's also a matter of design, rather than just implementation. Commented Jan 18, 2019 at 4:01

1 Answer 1

Reset to default
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.

Improve this answer
1
  • // , 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. Commented Oct 28, 2020 at 7:18

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.