I want to have multiple “admin” tokens with associated policies.
One should be used for the regular use of creating policies with limited capabilities and tokens associated with it. This one must not be able to gain additional privileges.
The idea is to have this in that admin policy:
[...]
path "secrets/data/*" {
capabilities = ["create", "update", "read", "delete", "list"]
}
path "sys/policies/acl/user-*" {
capabilities = ["read", "create", "update", "delete"]
}
And then create “user-xxx” policies that have only permissions on “secrets/data/xxx/*”.
i.e.
$ vault policy write user-john /tmp/john.hcl
$ vault token create -policy user-john
However the token creating fails with “child policies must be subset of parent”.
So it looks like the list of policy names is enforced, not the actual permissions, it doesn’t even work then the user policy is empty.
One solution is to add “sudo” to the “auth/token/create” endpoint in that admin policy. But this not only allows to create the user tokens, but also tokens for other, less restricted admin policies. Due to being able to create policies (for which tokens can then also be created) any permission can be gained by that, making it impossible to restrict such an “admin” token.
The name of the user policies is not fixed at the start, so new names must be added without prior use of the root token. But even using roles to allow creating tokens only for policies with specified names won’t restrict the effective permissions as those policies could also be extended by permissions not present in the current policy.
It is possible to restrict creating/changing policies to specific names to especially disallow changing the admin policy with the token of the admin policy.
But is there any way to restrict the creation of tokens to policies that have permissions that are a subset of the policy the issuing token belongs to?