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
6.6 KiB
| layout | page_title | sidebar_title | sidebar_current | description |
|---|---|---|---|---|
| docs | Upgrading to Vault 0.5.0 - Guides | Upgrade to 0.5.0 | docs-upgrading-to-0.5.0 | This page contains the full list of breaking changes for Vault 0.5, including actions you must take to facilitate a smooth upgrade path. |
Overview
This page contains the list of breaking changes for Vault 0.5. Please read it carefully.
Please note that these are changes to Vault itself. Client libraries maintained by HashiCorp have been updated with support for these changes, but if you are using community-supported libraries, you should ensure that they are ready for Vault 0.5 before upgrading.
Rekey Requires Nonce
Vault now generates a nonce when a rekey operation is started in order to ensure that the operation cannot be hijacked. The nonce is output when the rekey operation is started and when rekey status is requested.
The nonce must be provided as part of the request parameters when providing an unseal key. The nonce can be communicated from the request initiator to unseal key holders via side channels; the unseal key holders can then verify the nonce (by providing it) when they submit their unseal key.
As a convenience, if using the CLI interactively to provide the unseal key, the nonce will be displayed for verification but the user will not be required to manually re-type it.
TTL Field in Token Lookup
Previously, the ttl field returned when calling lookup or lookup-self on
the token auth method displayed the TTL set at token creation. It
now displays the time remaining (in seconds) for the token's validity period.
The original behavior has been moved to a field named creation_ttl.
Grace Periods Removed
Vault no longer uses grace periods internally for leases or token TTLs.
Previously these were set by backends and could differ greatly from one backend
to another, causing confusion. TTLs (the lease_duration field for a lease,
or, for a token lookup, the ttl) are now exact.
token-renew CLI Command
If the token given for renewal is the same as the token in use by the client,
the renew-self endpoint will be used in the API rather than the renew
endpoint. Since the default policy contains auth/token/renew-self this
makes it much more likely that the request will succeed rather than somewhat
confusingly failing due to a lack of permissions on auth/token/renew.
status CLI Command
The status CLI command now returns an exit code of 0 for an unsealed Vault
(as before), 2 for a sealed Vault, and 1 for an error. This keeps error
return codes consistent across commands.
Transit Upsertion Behavior Uses Capabilities
Previously, attempting to encrypt with a key that did not exist would create a
key with default values. This was convenient but ultimately allowed a client to
potentially escape an ACL policy restriction, albeit without any dangerous
access. Now that Vault supports more granular capabilities in policies,
upsertion behavior is controlled by whether the client has the create
capability for the request (upsertion is allowed) or only the update
capability (upsertion is denied).
etcd Physical Backend Uses sync
The etcd physical backend now supports sync functionality and it is turned
on by default, which maps to the upstream library's default. It can be
disabled; see the configuration page for information.
S3 Physical Backend Prefers Environment Variables
The s3 physical backend now prefers environment variables over configuration
file variables. This matches the behavior of the rest of the backends and of
Vault generally.
Lease Default and Renewal Handling
All backends now honor system and mount-specific default and maximum lease times, except when specifically overridden by backend configuration or role parameters, or when doing so would not make sense (e.g. AWS STS tokens cannot have a lifetime of greater than 1 hour).
This allows for a much more uniform approach to managing leases on both the operational side and the user side, and removes much ambiguity and uncertainty resulting from backend-hardcoded limits.
However, also this means that the leases generated by the backends may return
significantly different TTLs in 0.5 than in previous versions, unless they have
been preconfigured. You can use the mount-tune CLI command or the
/sys/mounts/<mount point>/tune endpoint to adjust default and max TTL
behavior for any mount. This is supported in 0.4, so you can perform this
tuning before upgrading.
The following list details the ways in which lease handling has changed per-backend. In all cases the "mount TTL" means the mount-specific value for default or max TTL; however, if no value is set on a given mount, the system default/max values are used. This lists only the changes; any lease-issuing or renew function not listed here behaves the same as in 0.4.
(As a refresher: the default TTL is the amount of time that the initial lease/token is valid for before it must be renewed; the maximum TTL is the amount of time a lease or token is valid for before it can no longer be renewed and must be reissued. A mount can be more restrictive with its maximum TTL, but cannot be less restrictive than the mount's maximum TTL.)
Credential (Auth) Backends
github– The renewal function now uses the backend's configured maximum TTL, if set; otherwise, the mount maximum TTL is used.ldap– The renewal function now uses the mount default TTL instead of always using one hour.token– Tokens can no longer be renewed forever; instead, they now honor the mount default/max TTL.userpass– The renew function now uses the backend's configured maximum TTL, if set; otherwise the mount maximum TTL is used.
Secrets Engines
aws– New IAM roles no longer always have a default TTL of one hour, instead honoring the configured default if available and the mount default TTL if not (renewal always used the configured values if available). STS tokens return a TTL corresponding to the lifetime of the token in AWS and cannot be renewed.cassandra–lease_grace_periodhas been removed since Vault no longer uses grace periods.consul– The mount default TTL is now used as the default TTL if there is no backend configuration parameter. Renewal now uses the mount default and maximum TTLs.mysql– The mount default TTL is now used as the default TTL if there is no backend configuration parameter.postgresql– The mount default TTL is now used as the default TTL if there is no backend configuration parameter. In addition, there is no longer any grace period with the time configured for password expiration within Postgres itself.