open-vault/website/pages/docs/upgrading/upgrade-to-1.3.0.mdx

59 lines
2.7 KiB
Plaintext
Raw Normal View History

2019-11-14 17:10:39 +00:00
---
layout: docs
page_title: Upgrading to Vault 1.3.0 - Guides
sidebar_title: Upgrade to 1.3.0
2019-11-14 17:10:39 +00:00
description: |-
This page contains the list of deprecations and important or breaking changes
for Vault 1.3.0. Please read it carefully.
---
# Overview
This page contains the list of deprecations and important or breaking changes
for Vault 1.3.0 compared to 1.2.4. Please read it carefully.
## Secondary cluster activation
2019-11-14 17:10:39 +00:00
There has been a change to the way that activating performance and DR secondary
clusters works when using public keys for encryption of the parameters rather
than a wrapping token. This flow was experimental and never documented. It is
now officially supported and documented but is not backwards compatible with
older Vault releases.
## Cluster cipher suites
2019-11-14 17:10:39 +00:00
On its cluster port, Vault will no longer advertise the full TLS 1.2 cipher
suite list by default. Although this port is only used for Vault-to-Vault
communication and would always pick a strong cipher, it could cause false flags
on port scanners and other security utilities that assumed insecure ciphers were
being used. The previous behavior can be achieved by setting the value of the
(undocumented) cluster_cipher_suites config flag to tls12.
## API/Agent Renewal Behavior
The API now allows multiple options for how it deals with renewals. The legacy
behavior in the Agent/API is for the renewer (now called the lifetime watcher)
to exit on a renew error, leading to a reauthentication. The new default
behavior is for the lifetime watcher to ignore 5XX errors and simply retry as
scheduled, using the existing lease duration. It is also possible, within
custom code, to disable renewals entirely, which allows the lifetime watcher to
simply return when it believes it is time for your code to renew or
reauthenticate.
## Filtered Mount Replication Deprecation
As of 1.3.0, paths that were once filtered with
[Filtered Mount Replication](/api-docs/system/replication/replication-performance#create-mounts-filter-deprecated)
are migrated to use
[Filtered Paths Replication](/api-docs/system/replication/replication-performance#create-paths-filter).
The APIs are very similar, but as of 1.3.0, we have marked the mount filter API as
deprecated and recommend migrating to the path filter API, as the mount filter
API will be removed in a future version of Vault.
In versions of Vault prior to 1.3.0, mount filters could be used to allow
only specified mounts to replicate to secondary nodes via an allowlist
(referred to as a whitelist in the original documentation of the feature). After
upgrade to 1.3.0 and later, if allowlist/whitelist mount filters were enabled
on a secondary node, namespaces and their default mounts will also stop
replicating to that secondary node.