Non root token that can create new tokens with newly created policy

Vault
1

I am quite new to vault and maybe i am missing something.

I am trying to create a script uploads 2 secrets in a path example
/secret/data/“nameoffolder”/secret1
/secret/data/“nameoffolder”/secret2

that part is working fine. now i want to create policy that only have read access to /secret/data/“nameoffolder”/*

That policy is fine too. My issue is that when trying to create a token that uses that policy i get the following error:
Error creating token: Error making API request.

URL: POST https://*:8201/v1/auth/token/create
Code: 400. Errors:

  • child policies must be subset of parent

I am using a token with the following policy:

path “auth/token/*” {
capabilities = [“create”, “read”, “update”, “delete”, “list”]
}

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

path “sys/policies/*” {
capabilities = [“create”, “read”, “update”, “delete”, “list”]
}

When trying with root token it works fine. If i create a new token that uses both policies i can create the token.

Is there a way for me to do as started. the whole goal is to automatically upload, create a policy when read access and then create a token that uses that policy. But would like to not use the root token. Hope someone can assist.

2

Alongside the 5 common capabilities (create, read, update, delete, list), Vault has another capability named sudo.

The name is an allusion to the Unix tool of the same name, but it’s IMO not a very good name choice, since it has very little in common.

It is also not documented well in the Vault documentation.

Unlike all other capabilities, sudo needs to be applied in addition to one of the other capabilities, and it has the meaning of “unlock extra privileged functionality”. It’s aim seems to be to force the author of an ACL policy to make it explicit that they truly do mean to unlock access to an unusually privileged endpoint.

Most Vault endpoints that require sudo capability simply block access entirely if you don’t have it. But, the auth/token/create family of endpoints is unique (AFAIK), in that they work normally without sudo, but unlock extra functionality when the sudo capability is granted.

Documentation for this family of endpoints is here: Token - Auth Methods - HTTP API | Vault | HashiCorp Developer

3

From the link above:

A list of policies for the token. This must be a subset of the policies belonging to the token making the request, unless the calling token is root or contains sudo capabilities to auth/token/create .

Does the token being used to create the restricted token have the same policy linked to it? I don’t mean the same capabilities because obviously it has more capabilites, I mean the actual policy.

4

Yes, that’s correct.

5

Added the Sudo right to the policy and that seems to have fixed the token creation issue.
Though i am wondering if i am creating a security issue with doing this.

My goal is to automate my secret upload and make a token that have access to only that secret. but from what i can see i would need to

  1. use the root token(not a good solution)
  2. use the sudo capability
  3. give the token i use for creating the policy and token access to the newly created policy.(this just seems to be odd that its nessary as it have access with the wildcard)
6

Perhaps you should use a different approach then.

If you want to make policies “dynamic” in the sense that they will take an identifier from the authenticating principal (an app or script as you mentioned), you can use templates in your policy grants, you don’t need to create multiple policies.

And if you need a consistent way for authenticating your apps without having to issue tokens manually, you should look into the AppRole, TLS client certificates or (if applicable) Kubernetes auth method.