Policy issues using sub folder permissions

Vault
1

Hi Guys,

I am trying to create a policy which enables “admin” access using a token within a folder inside a secrets engine. I am having some problems in assiging the correct permissions to allow the token to create, update, read anything within its sub folder.

The structure I have is as follows.

assets/ssl/domain

assets kv secret engine created with vault secrets enable -path=assets kv-v2

Policy created with:

# Enable and manage the key/value secrets engine at  path

path "assets/*"
{
  capabilities = ["read", "list", "sudo"]
}

# List, create, update, and delete key/value secrets
path "assets/ssl/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

Policy tied with:

vault policy write cert-admin cert-admin-policy.hcl

Token created with:
vault token create -policy=cert-admin -period=24h

certs that I want stored/uploaded using the following snipet

  vault kv put \
    "assets/ssl/$domain" \
    "cert=@$RENEWED_LINEAGE/cert.pem" \
    "fullchain=@$RENEWED_LINEAGE/fullchain.pem" \
    "privkey=@$RENEWED_LINEAGE/privkey.pem"

Now if I just have a single policy as:

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

It works correctly within the ssl folder, however if I try and restrict it so its just within assets/ssl thats when im having a problem.

When I test the token using the UI, it clearly says permission denied. I have tried various versions of the first policy but its still not doing what I would of expected.

Does anyone have a clue on what I am doing wrong?

I know a work around woud be to use a dedicated kv store for it but thats not really ideal for me.

Any thoughts/suggestions what I am doing wrong?

Kind Regards,

2

If you are using K/V version 2 the paths you use in API calls are not the same as the secret path presented to the user (unlike in K/V version 1). To allow the additional versioning functionality you need to add /data to the API call to return the most recent version of a secret (or update it).

So, for example, the secret /ssl/secret would be accessed using the API path /data/ssl/secret.

When writing policies it is the API paths that you are granting permissions to. You will need to grant access to /data/ssl (rather than just /ssl) as well as any of the other paths you want (such as /metadata or /delete) - see the API documentation for the details (KV - Secrets Engines - HTTP API | Vault by HashiCorp)

3

Hi @stuart-c

Thanks very much for filling this in, makes more sence now and yes im using v2.

Kind Regards,

Simon