Description
This article explains the behaviour of token role updates in Vault, specifically regarding allowed_policies. It also provides a workaround to update token capabilities without regenerating tokens.
Problem Statement
A user configures a token role in Vault with specific policies.
vault write auth/token/roles/<role-name> allowed_policies=A bound_cidrs="10.25.90.X" orphan=true period=32d
vault token create -role=<role-name>
Later, there's a need to expand the scope by updating the token role:
vault write auth/token/roles/<role-name> allowed_policies=B bound_cidrs="10.25.89.X" orphan=true period=32d
However, the original token (let’s call it Token X) continues to operate with the old configuration (Policy A,). The new policy (B) has no effect on Token X. This poses a challenge in production environments where applications are tightly coupled with existing tokens, and changing tokens frequently is not feasible.
Workaround
While existing tokens cannot inherit changes to role properties such asbound_cidrsBut there is a way to reflect the updated policy in the existing token.
-
Update the existing policy (e.g., Policy A) with the required permissions instead of creating new policies.
-
Once the policy is modified, re-authenticating with the same token will reflect the updated capabilities, since the token is still bound to that policy.
-
However, changes to other role-level configurations, like bound_cidrs, will not be reflected on existing tokens. CIDR bindings are embedded at token creation and cannot be altered retroactively.
Conclusion
In Vault, token role updates do not affect existing tokens. Role properties such as allowed_policies and bound_cidrs are only evaluated at token creation. Therefore, to avoid reissuing tokens:
-
Modify existing policies attached to the token instead of updating roles.
-
For changes like CIDRs, a new token must be created and distributed to the application.
This limitation is by design and is important to consider when designing secure and scalable Vault integrations.