How to enforce the policy and role when creating tokens?

Vault
1

I want to create a “deploy” token for the sole purpose of creating child “app” tokens with restrictive properties like short TTL, no renew, etc. So I created a token policy for the “deploy” token with this HCL:

path "auth/token/create/*" {
  capabilities = ["update"]
  allowed_parameters = {
    "policy" = ["app_policy"]
    "role" = ["app_role"]
  }
  required_parameters = ["policy", "role"]
}

But I always get “Permission denied” when creating “app” tokens while authenticated with the “deploy” token using a command like this:

vault token create -role=app_role -policy=app_policy

If I omit the allowed_parameters and required_parameters, the token can be created as expected. What is the correct way to get the behavior I’m looking for? Thanks in advance!

2

Please refer to the API docs: https://www.vaultproject.io/api-docs/auth/token#create-token

There is no parameter policy to this API, it is called policies.

There is no parameter role to this API, the role name appears in the URL path, not as a named parameter that can be controleld with allowed_parameters / required_parameters.

The allowed policies connected with a token role should be configured in the role - https://www.vaultproject.io/api-docs/auth/token#create-update-token-role and not via allowed_parameters in the ACL policy.

3

Oh dear, I was referring to the CLI docs from vault token create --help instead of the API docs. Thanks for pointing me in the right direction.

I noticed that allowed_policies in the role must include both the policy for the “deploy” token and the “app” token:

allowed_policies="deploy, app"

This has the undesired effect of allowing “deploy” tokens to create more “deploy” tokens. I was able to resolve this in the policy by restricting the role in the path (i.e. replace * with app):

path "auth/token/create/app" {
  capabilities = ["update"]
}
4

I’m not 100% sure but you could also implement something like this via a control-group policy but that requires an Enterprise license. We use these to manage, yes allowed to access, but it requires pre-authorization on each request. You would normally use it to restrict blanket access to a secret but I don’t think the path is particular to secret engines and “MAYBE” usable in an token as well.

5

Control groups are used to require requests to be approved by another identity. They are not relevant to the problem described here.

Someone in the community flagged this as off-topic for some reason. It’s clearly not, since it’s a direct response to content earlier in the thread.

6

Please do not use moderation tools such as marking something “off-topic” or spam when it’s simply a reply you disagree with. Please review the Community Guidelines and consider that there’s a fellow human being on the other side of these posts. Thank you.

1 Like