This page contains the list of deprecations and important or breaking changes for Vault 0.6.4. Please read it carefully.
Note: both of these are security sensitive changes.
default Policy Addition Rules for
An issue was reported indicating that in some cases, the stated behavior of the
default policy being added to tokens unless specifically requested could lead
to a privilege escalation scenario if the parent token did not itself have the
default policy. In most cases (e.g. using the default
default policy) the
escalated privileges are unlikely to be dangerous, but this behavior is
As such, we have modified the rules around
default in a few ways when
creating tokens using this endpoint:
- If a token creation request does not specify desired policies, the parent's
policies will be used (as normal) but
defaultwill not be automatically added, so the child token will only have
defaultif the parent does
- If a token creation request specifies desired policies,
defaultwill be added automatically if and only if the parent token has
- If the parent token has
sudocapability on the token creation endpoint,
defaultis always added; since
sudocapability on this endpoint allows adding any policy, this is not privilege escalation with respect to the parent token-holder
- When using token store roles,
defaultis always added to the list of child token policies unless
defaultis contained in
Regardless of provenance, if a token being created has the
no_default_policy has been set
true for the request, the
policy will be stripped from the final set of policies.
Many Users Should Run
While investigating a report of accessor entries not being removed correctly from Vault's data store, a security issue was discovered: if limited use-count tokens are being used and expire due to the use-count dropping to zero (rather than due to the token's TTL expiring or the token being explicitly revoked), several pieces of Vault's token revocation logic would not be properly run. This included cleaning up the associated accessor entry from the data store, but more importantly, included the logic used to immediately expire leases associated with the token.
These leases would not live forever; they would still be expired when their TTL ran out. This limits the severity of this issue, but it is still a potentially serious bug depending on each particular operational scenario.
To mitigate this issue we have taken the following steps:
Updated the token revocation logic to be more resilient to failures that can happen as it performs its various steps; the revocation will now properly only be considered successful if no error has occurred. In addition, the token entry will remain in the data store (but not be usable for performing Vault functions) until all aspects of revocation report success, allowing future revocation requests to succeed if the underlying cause of the failure has been addressed.
Added a function
auth/token/tidythat can both clean up the leaked accessor entries and expire the leases associated with those accessors' tokens.
In most cases, running
auth/token/tidy should expire all outstanding
leases that were generated by these revoked limited-use-count tokens.
If you are both using limited-use-count tokens and you are using them to
issue leased secrets, you should consider upgrading to 0.6.4 and running the
auth/token/tidy endpoint immediately. Please note that running this function
involves a lot of requests to the data store, so plan load accordingly.
Note: response wrapping tokens do not allow generating leases but have still been subject to leaking the accessor entries, so if you have been a heavy user of response wrapping you should still consider running the tidy function.