a3dfde5cec
* conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
86 lines
4.2 KiB
Markdown
86 lines
4.2 KiB
Markdown
---
|
|
layout: "docs"
|
|
page_title: "Upgrading to Vault 0.6.4 - Guides"
|
|
sidebar_title: "Upgrade to 0.6.4"
|
|
sidebar_current: "docs-upgrading-to-0.6.4"
|
|
description: |-
|
|
This page contains the list of deprecations and important or breaking changes
|
|
for Vault 0.6.4. Please read it carefully.
|
|
---
|
|
|
|
# Overview
|
|
|
|
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.
|
|
|
|
## Changes to `default` Policy Addition Rules for `auth/token/create`
|
|
|
|
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
|
|
undesired.
|
|
|
|
As such, we have modified the rules around `default` in a few ways when
|
|
creating tokens using this endpoint:
|
|
|
|
1. If a token creation request does not specify desired policies, the parent's
|
|
policies will be used (as normal) but `default` will not be automatically
|
|
added, so the child token will only have `default` if the parent does
|
|
2. If a token creation request specifies desired policies, `default` will be
|
|
added automatically if and only if the parent token has `default`
|
|
3. If the parent token has `sudo` capability on the token creation endpoint,
|
|
`default` is always added; since `sudo` capability on this endpoint allows
|
|
adding any policy, this is not privilege escalation with respect to the
|
|
parent token-holder
|
|
4. When using token store roles, `default` is always added to the list of child
|
|
token policies unless `default` is contained in `disallowed_policies`
|
|
|
|
**Regardless of provenance**, if a token being created has the `default` policy
|
|
and `no_default_policy` has been set `true` for the request, the `default`
|
|
policy will be stripped from the final set of policies.
|
|
|
|
## Many Users Should Run `auth/token/tidy`
|
|
|
|
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:
|
|
|
|
1. 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.
|
|
|
|
2. Added a function `auth/token/tidy` that 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.
|