Wildcard in policy path doesn't work with prefix

I need to create a policy for all paths that start with a certain name, like “team-”. But a wildcard character with a prefix does not seem to work in Vault.

$ vault policy read test-role-policy
 path "/auth/approle/role/team-example/role-id" { capabilities = ["create", "read", "update", "delete", "list"] }
$ vault policy read test-role-policyn
 path "/auth/approle/role/team-*/role-id" { capabilities = ["create", "read", "update", "delete", "list"] }
$ TOKENR=$(vault token create -format=json -policy=test-role-policy -period=1h | jq -r ".auth.client_token")
$ vault token capabilities ${TOKENR} /auth/approle/role/team-example/role-id
 create, delete, list, read, update
$ TOKENW=$(vault token create -format=json -policy=test-role-policyn -period=1h | jq -r ".auth.client_token")
$ vault token capabilities $TOKENW /auth/approle/role/team-example/role-id
 deny

As seen above, when I provide full name in the path, the token issued works fine but with a wildcard, it doesn’t work on the same path (/auth/approle/role/team-example/role-id)

Hi,

The glob/asterik is only supported as a wildcard when its the last character of the path.

I’d recommend not doing pseudo-pathing with “team-” in a path as shown:
/auth/approle/role/team-*/role-id, but, make your paths like:
/auth/approle/role/team/teamA/role-id
which then you can wildcard to just the team’s with:
/auth/approle/role/team/+/role-id

You can read more here:

2 Likes

Hi Mike, thanks for the response

I don’t think that kind of path is supported. The role-name cannot have a slash in it.

$ vault write auth/approle/role/team/teamA/my-role token_num_uses=0
Error writing data to auth/approle/role/team/teamA/my-role: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/auth/approle/role/team/teamA/my-role
Code: 404. Errors:

* 1 error occurred:
	* unsupported path

Ah, not enough coffee earlier… Yes, I’m wrong on the abilty to do that pathing within the approle path.
So that combined with the limitation you can’t use wildcards except at the end might require a redesign here.

What is your use case, in terms of you want to lock down just the role-id (vs secret-id or such) but only to roles that start w/ team?

I want to only allow the approle to create the role-id and later use a token to create secret-id for that role, so that I can distribute the role-id to the teams and add the token in the infra. This way, one party doesn’t have both the info necessary to access the secrets and we generate short-lived secret-id when needed.
Here’s a detailed description of this usecase: https://github.com/bruj0/vault_jenkins#reading-secrets-from-jenkins

How about a policy for the teams to deny them all role-id?

path "/auth/approle/role/+/role-id" {
  capabilities = ["deny"]
}