Creating Token for kv policy

Moin,

I followed the instraction on [1] and [2] to generate a policy for kv secrets and the appropriate token for it. But I’m missing something, because the token doesn’t work.

What I did:

# vault secrets enable -version=2 -path=secret/ kv
# vault policy write wia policy_wia_kv.hcl
# cat policy_wia_kv.hcl 
path "secret/data/bmb/wia/*" {
  capabilities = ["create", "read"]
}

This works with the admin token:

# vault kv put secret/data/bmb/wia my-value=s3cr3t
Key              Value
---              -----
created_time     2023-03-14T13:35:36.586348845Z
deletion_time    n/a
destroyed        false
version          1

Another token should be used for access:

# vault token create -policy="wia" -field=token
s.7lpwYjxW9QTnauCBkSOCAaKF

So now continue with this token,

$ unset VAULT_TOKEN
$ vault login
Token (will be hidden): <the new token for this policy>

but it doesn’t work that way

$ vault token capabilities secret/data/bmb/wia
deny

What did I wrong? Grateful for hints.

Micha

[1] Hashicorp Vault - ACL Policies | Mike Polinowski
[2] kv get - Command | Vault | HashiCorp Developer

There are two problems here:

First, the path in

does not match the path in the policy

because the policy only matches things with a slash after wia

Second, it looks like you may have explicit deny capabilities set in other policies not mentioned here, which may interfere. (Based on the output of the vault token capabilities command.)

Because you need to add the data in you path, needs to be like so:

path “secret/data/data/bmb/wia” {
capabilities = [“read”]
}
Notice double “data”
and it should work, data is added automatically, and you have created the secret with data as a parent.

Then get the secret as so:

vault kv get secret/data/bmb/wia

OK, good spot, the path given in

doesn’t match the path used elsewhere in the post, since the vault kv ... series of commands inserts the extra path segment that is part of the KVv2 API.

That said, my read of the post is it’s more likely that the policy is correct, and the fix is to remove the data path segment from the vault kv commands.

Moin,

thanks for all the answers. I had decided to start again from the beginning, but unfortunately it doesn’t work yet. I checked the “my-value” key from yesterday, it was still there. After that I disabled secret and enabled it again. As expected, the key was then not present.

# vault kv get -field=my-value secret/data/bmb/wia
s3cr3t
# vault secrets disable secret/
Success! Disabled the secrets engine (if it existed) at: secret/
# vault kv get -field=my-value secret/data/bmb/wia
Error making API request.

URL: GET https://localhost:8200/v1/sys/internal/ui/mounts/secret/data/bmb/wia
Code: 403. Errors:

* preflight capability check returned 403, please ensure client's policies grant access to path "secret/data/bmb/wia/"

Now I adjusted the policy (no wildcard and a sinlge “data” and activated kv again. It’s working, at least for the admin.

# cat policy_wia_kv.hcl
path "secret/data/bmb/wia" {
  capabilities = ["create", "read", "list"]
}

# vault secrets enable -version=2 -path=secret/ kv
# vault policy write wia policy_wia_kv.hcl
Success! Uploaded policy: wia

# vault kv put secret/bmb/wia my-value=s3cr3t
Key              Value
---              -----
created_time     2023-03-15T09:51:39.289559138Z
deletion_time    n/a
destroyed        false
version          1

Now create the token for the user and continue working with this token in an other terminal.

# vault token create -policy="wia" -field=token
s.F3xoYimMkkwaQ0CheyeJY395

And now with this Token … after that I don’t understand. Because the user can read the previously set secret, but cannot write one. And the capabilities require the “data” in the path?

$ vault login
Token (will be hidden): 
Success! You are now authenticated. The token information displayed below
.
.
.
$ vault kv get -field=my-value secret/bmb/wia
s3cr3t
$ vault token capabilities secret/data/bmb/wia
create, list, read
$ vault token capabilities secret/bmb/wia
deny

$ vault kv put secret/bmb/wia my-value2=s3cr3t
Error writing data to secret/data/bmb/wia: Error making API request.

URL: PUT https://localhost:8200/v1/secret/data/bmb/wia
Code: 403. Errors:

* 1 error occurred:
        * permission denied

Now i’m at a loss. I’m still missing a piece of information somewhere :frowning:

I think you’re missing the “update” capability now.

“create” only applies when there is no existing value. “update” allows you to overwrite/update an existing value.

In addition to that, the list capability is inapplicable to the data/ subpath of KV v2 engines - the list operation is performed against the metadata/ subpath.

The URL layout of the KV v2 secrets engine confuses many people - if you’re going to be using them, it is good to take some time to carefully read through what operations exist on the various KV v2 subpaths.

On my side is working as i mentioned above:

wia policy with only read:

cat policy_wia_kv.hcl

path “secret/data/bmb/wia/*” {
capabilities = [“read”]
}

vault kv put secret/data/bmb/wia my-value=s3cr3t

vault token create -policy=“wia” -field=token

Login with the token

vault login hvs.CAESICxxxxxxxxxxxxx

vault kv get secret/data/bmb/wia

======= Metadata =======
Key Value


created_time 2023-03-14T14:37:22.669328911Z
custom_metadata
deletion_time n/a
destroyed false
version 1

====== Data ======
Key Value


my-value s3cr3t

This is to read, to write, update, you need to add update.

Moin, thank you all. It works now. For the archive only: The policy looks like this:

path "secret/data/bmb/wia" {
  capabilities =  ["create", "read", "update", "delete", "list"]
}

and with the user token I can now write and read.

$ vault kv put secret/bmb/wia user-value3=s3cr3t
Key              Value
---              -----
created_time     2023-03-15T15:41:54.509914768Z
deletion_time    n/a
destroyed        false
version          4
$ vault kv get -field=user-value3 secret/bmb/wia
s3cr3t

Now let’s move on to using the API.

Micha