Getting permission denied when using a token generated in Hashicorp vault

Vault
1

Hi Team,
Can you please assist me with the below given post about using the policy to allow access to a token to read secrets from Vault.

when-using-a-token-generated-in-hashicorp-vault/71362039#71362039

2

I think part of your trouble may be related to disabling the default policy on the created token.

If you’re using KVv2 and the web UI, you will also need to grant list and read to secret/metadata/* if clients-integration is a secret or
secret/metadata/clients-integration/ AND secret/metadata/clients-integration/* if clients-integration is intended to be a folder (if a folder you’ll have to add a /* at the end of your data path too).

Some important bits from the default policy:

# Allow tokens to look up their own properties
path "auth/token/lookup-self" {
  capabilities = ["read"]
}

# Allow tokens to renew themselves
path "auth/token/renew-self" {
  capabilities = ["update"]
}

# Allow tokens to revoke themselves
path "auth/token/revoke-self" {
  capabilities = ["update"]
}

# Allow a token to look up its own capabilities on a path
path "sys/capabilities-self" {
  capabilities = ["update"]
}
# <-- SNIP -->
# Allow a token to look up its resultant ACL from all policies. This is useful
# for UIs. It is an internal path because the format may change at any time
# based on how the internal ACL features and capabilities change.
path "sys/internal/ui/resultant-acl" {
  capabilities = ["read"]
}
# <-- SNIP -->
3

Sorry for the delay in getting back, I was held up with some personal emergency. Here is the secretes created in the UI as root user

image
image3261Ă—738 64.8 KB

I have created the readonly user as follows

vault token create -policy=caffe-readonly default -display-name=caffe-parser-test-suite

The policy called as caffe-readonly is as given below,

# Allow tokens to look up their own properties
path "auth/token/lookup-self" {
  capabilities = ["read"]
}

# Allow tokens to renew themselves
path "auth/token/renew-self" {
  capabilities = ["update"]
}

# Allow tokens to revoke themselves
path "auth/token/revoke-self" {
  capabilities = ["update"]
}

# Allow a token to look up its own capabilities on a path
path "sys/capabilities-self" {
  capabilities = ["update"]
}
# <-- SNIP -->
# Allow a token to look up its resultant ACL from all policies. This is useful
# for UIs. It is an internal path because the format may change at any time
# based on how the internal ACL features and capabilities change.
path "sys/internal/ui/resultant-acl" {
  capabilities = ["read"]
}
# <-- SNIP -->

# allow permission to read the metadata
path "secret/metadata/*" {
  capabilities = ["read","list"]
}

path "secret/metadata/clients-integration/" {
  capabilities = ["read","list"]
}

path "secret/metadata/clients-integration/*" {
   capabilities = ["read","list"]
}

path "secret/data/clients-integration/*" {
    capabilities = ["read"]
}

When I login to the portal using the token generated for the above user, I am getting below screen only without KV engine enabled

image
image3399Ă—582 22.6 KB

When I am trying to get the secrets through the API, I am getting below response,

{
    "errors": [
        "1 error occurred:\n\t* permission denied\n\n"
    ]
}

I feel that I am not giving the permission to the KV engine to token, but not sure if anything is missing… When I create the user, the user has both the caffe-readonly and the default policy in the token.
Can you please help me

4

From your StackOverflow post, and your screenshot in this forum, it is apparent that your KV secrets engine is mounted at path kv/.

However none of the ACL policies you’ve shown, grant any access to paths starting with kv/.

Therefore you don’t have permission to access it.

Try starting with

path "kv/*" {
  capabilities = ["read", "list", "create", "update", "delete"]
}

and locking things down further once you’ve got that working.

Also, whilst it’s unrelated to the immediate problem, consider not using -no-default-policy - the default policy is there for good reason, and should not usually be switched off.

1 Like
5

Your policy snipped worked !!!
Thanks a lot for your response :slightly_smiling_face:

6

Further, when i tried with the below policy, I am able to view the data for clients-integration which should have been disabled with “deny”

# Allow tokens to look up their own properties
path "auth/token/lookup-self" {
  capabilities = ["read"]
}

# Allow tokens to renew themselves
path "auth/token/renew-self" {
  capabilities = ["update"]
}

# Allow a token to look up its own capabilities on a path
path "sys/capabilities-self" {
  capabilities = ["update"]
}
# <-- SNIP -->
# Allow a token to look up its resultant ACL from all policies. This is useful
# for UIs. It is an internal path because the format may change at any time
# based on how the internal ACL features and capabilities change.
path "sys/internal/ui/resultant-acl" {
  capabilities = ["read"]
}
# <-- SNIP -->
path "kv/*" {
  capabilities = ["read","list", "create", "update"]
}
path "kv/secret/data/*" {
  capabilities = ["list", "create", "update"]
}
path "secret/clients-integration/*" {
  capabilities = ["deny"]
}

Now that the token is able to get all the secrets, the deny is not applied by default and when we apply also, it is not working. Can you please review and help

7

The deny will work fine… for the path you’ve configured it on. But that path doesn’t correspond to anything in your Vault.

All paths that you write in your policies need to correspond correctly to the URL-path used to make the relevant requests to Vault - that’s how they work.

There are two mistakes you’re making:

  1. Leaving out the path where the KV secrets engine is mounted.

  2. Arbitrarily inserting /data/, but not always, and not always in the right place.

My guess is you actually mean:

path "kv/metadata/secret/*" {
  capabilities = ["list"]
}

path "kv/data/secret/*" {
  capabilities = ["create", "update"]
}

path "kv/data/secret/clients-integration/*" {
  capabilities = ["deny"]
}

Possibly this one too:

path "kv/metadata/secret/clients-integration/*" {
  capabilites = ["deny"]
}

If you’re writing policies for KV v2 secrets engines, it’s vital you carefully look through KV - Secrets Engines - HTTP API | Vault by HashiCorp until you understand the 6 different endpoints within a KV v2:

  • /config
  • /metadata/…
  • /data/…
  • /delete/…
  • /undelete/…
  • /destroy/…
8

That was brilliant, worked fine. Thank you @maxb :slightly_smiling_face: