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
106 lines
4.4 KiB
Markdown
106 lines
4.4 KiB
Markdown
---
|
|
layout: "docs"
|
|
page_title: "Upgrading to Vault 0.6.1 - Guides"
|
|
sidebar_title: "Upgrade to 0.6.1"
|
|
sidebar_current: "docs-upgrading-to-0.6.1"
|
|
description: |-
|
|
This page contains the list of breaking changes for Vault 0.6.1. Please read
|
|
it carefully.
|
|
---
|
|
|
|
# Overview
|
|
|
|
This page contains the list of breaking changes for Vault 0.6.1. Please read it
|
|
carefully.
|
|
|
|
## Standby Nodes Must Be 0.6.1 As Well
|
|
|
|
Once an active node is running 0.6.1, only standby nodes running 0.6.1+ will be
|
|
able to form an HA cluster. If following our [general upgrade
|
|
instructions](/guides/upgrading/index.html) this will
|
|
not be an issue.
|
|
|
|
## Health Endpoint Status Code Changes
|
|
|
|
Prior to 0.6.1, the health endpoint would return a `500` (Internal Server
|
|
Error) for both a sealed and uninitialized state. In both states this was
|
|
confusing, since it was hard to tell, based on the status code, an actual
|
|
internal error from Vault from a Vault that was simply uninitialized or sealed,
|
|
not to mention differentiating between those two states.
|
|
|
|
In 0.6.1, a sealed Vault will return a `503` (Service Unavailable) status code.
|
|
As before, this can be adjusted with the `sealedcode` query parameter. An
|
|
uninitialized Vault will return a `501` (Not Implemented) status code. This can
|
|
be adjusted with the `uninitcode` query parameter.
|
|
|
|
This removes ambiguity/confusion and falls more in line with the intention of
|
|
each status code (including `500`).
|
|
|
|
## Root Token Creation Restrictions
|
|
|
|
Root tokens (tokens with the `root` policy) can no longer be created except by
|
|
another root token or the
|
|
[`generate-root`](/api/system/generate-root.html)
|
|
endpoint or CLI command.
|
|
|
|
## PKI Backend Certificates Will Contain Default Key Usages
|
|
|
|
Issued certificates from the `pki` backend against roles created or modified
|
|
after upgrading will contain a set of default key usages. This increases
|
|
compatibility with some software that requires strict adherence to RFCs, such
|
|
as OpenVPN.
|
|
|
|
This behavior is fully adjustable; see the [PKI backend
|
|
documentation](/docs/secrets/pki/index.html) for
|
|
details.
|
|
|
|
## DynamoDB Does Not Support HA By Default
|
|
|
|
If using DynamoDB and want to use HA support, you will need to explicitly
|
|
enable it in Vault's configuration; see the
|
|
[documentation](/docs/configuration/index.html#ha_enabled)
|
|
for details.
|
|
|
|
If you are already using DynamoDB in an HA fashion and wish to keep doing so,
|
|
it is *very important* that you set this option **before** upgrading your Vault
|
|
instances. Without doing so, each Vault instance will believe that it is
|
|
standalone and there could be consistency issues.
|
|
|
|
## LDAP Auth Method Forgets Bind Password and Insecure TLS Settings
|
|
|
|
Due to a bug, these two settings are forgotten if they have been configured in
|
|
the LDAP backend prior to 0.6.1. If you are using these settings with LDAP,
|
|
please be sure to re-submit your LDAP configuration to Vault after the upgrade,
|
|
so ensure that you have a valid token to do so before upgrading if you are
|
|
relying on LDAP authentication for permissions to modify the backend itself.
|
|
|
|
## LDAP Auth Method Does Not Search `memberOf`
|
|
|
|
The LDAP backend went from a model where all permutations of storing and
|
|
filtering groups were tried in all cases to one where specific filters are
|
|
defined by the administrator. This vastly increases overall directory
|
|
compatibility, especially with Active Directory when using nested groups, but
|
|
unfortunately has the side effect that `memberOf` is no longer searched for by
|
|
default, which is a breaking change for many existing setups.
|
|
|
|
`Scenario 2` in the [updated
|
|
documentation](/docs/auth/ldap.html) shows an
|
|
example of configuring the backend to query `memberOf`. It is recommended that
|
|
a test Vault server be set up and that successful authentication can be
|
|
performed using the new configuration before upgrading a primary or production
|
|
Vault instance.
|
|
|
|
In addition, if LDAP is relied upon for authentication, operators should ensure
|
|
that they have valid tokens with policies allowing modification of LDAP
|
|
parameters before upgrading, so that once an upgrade is performed, the new
|
|
configuration can be specified successfully.
|
|
|
|
## App-ID is Deprecated
|
|
|
|
With the addition of of the new [AppRole
|
|
backend](/docs/auth/approle.html), App-ID is
|
|
deprecated. There are no current plans to remove it, but we encourage using
|
|
AppRole whenever possible, as it offers enhanced functionality and can
|
|
accommodate many more types of authentication paradigms. App-ID will receive
|
|
security-related fixes only.
|