Do batch tokens support wildcards in policies?

Vault
1

Hey there, I am using the latest version of Hashicorp Vault. I created a batch token via the CLI.

vault token create -type=batch -policy=my_policy

I noticed that custom policy paths with wildcards are ignored if the path has more than 1 component. As an example, this is my policy:

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

I have no permission to access the tokens if the secret is located at secret/username1234. However, if I change the path to secret/* I get access. Is this intentional?

Could policy path templates be the solution to my problem here? Unfortunately I don’t know which field could be the best substitute since many fields are n/a for batch tokens.

Thanks for any help!

2

Hello, welcome to the forums.

Um, no, that’s not true.

Yes because secret/username1234 literally does not match secret/username1234/* - it does not have a slash after username1234 like the pattern requires.

This is completely unrelated to your issue.

3

Hi max, thanks for the information. I believe I have to clarify my initial post. When I said that the secret is located at secret/username1234 I didn’t share the full secret path. The full secret path is secret/username1234/foo and the secret data is key-test=value-test.

Here is the order of commands of a newly created docker image, with the policy from above:

$ docker run --rm -p 8200:8200 -p 8201:8201 hashicorp/vault:1.14
# [...extract root hash and log in...]
$ export VAULT_ADDR='http://0.0.0.0:8200'
$ vault login
$ vault policy write my_policy my_policy.hcl
$ vault token create -type=batch -policy=my_policy
$ vault kv put -mount=secret username1234/foo foo=bar
======== Secret Path ========
secret/data/username1234/foo

======= Metadata =======
Key                Value
---                -----
created_time       2023-08-19T15:16:58.688608918Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            4

In a new terminal, I log in with the new printed token:

$ export VAULT_ADDR='http://0.0.0.0:8200'
$ vault login # with the new token
$ vault kv get -mount=secret username1234/foo
Error making API request.

URL: GET http://0.0.0.0:8200/v1/sys/internal/ui/mounts/secret
Code: 403. Errors:

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

Any idea what I am doing wrong?

Regarding the policy path templates, it is slightly unrelated to the original problem but it is related to the topic. Instead of creating plenty of policies for each users, I prefer to have a single policy that restricts batch tokens to its username path.

4

Two separate things are going wrong here.

First, you have not actually applied the policy you intended to, to the batch token.

You have shown the exact commands you used - this is great for clearing up confusion! - but you haven’t shown the output produced. When I attempt to replicate your commands, I get different results. Had you actually granted the token you used to make the last request access to anything within secret/, you would get a different error message.

Second, even if you had applied that policy, it still would not have worked - the policy you have is appropriate for a KV v1, but it is now clear you are working with a KV v2. The KV v2 secret engine inserts an extra URL path segment between the mount point, and the internal path to the secret. Please refer to a previous reply I wrote on this subject, here: Policies not working on more levels. OICD Auth - #2 by maxb

1 Like
5

Thanks a lot! I completely missed that the secret path is secret/data/username1234/foo and not secret/username1234/foo. If I adjust the policy and add data/ as well then it works. As feedback, the UI doesn’t display the data/ component, so that’s why I didn’t notice.

Btw, you said:

First, you have not actually applied the policy you intended to, to the batch token.

Isn’t this what I did with vault token create ... -policy=my_policy? To me it looks this policy is attached to the batch token.

6

Maybe it is, then, but the content in incorrect? The point is, that the message

is saying “your current identity has no access at all to any paths starting with secret/”.

I do not get that message when I follow the commands you listed.

Perhaps your my_policy.hcl file does not contain the intended content?

7

Ok, gotcha. After adding /data it doesn’t show up anymore. Thanks for the feedback and help! It all looked solved now. :slight_smile: