2019-11-14 17:10:39 +00:00
|
|
|
---
|
2020-01-18 00:18:09 +00:00
|
|
|
layout: docs
|
|
|
|
|
page_title: Upgrading to Vault 1.3.0 - Guides
|
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.
|
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
## 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.
|
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
## 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.
|
2020-01-08 17:47:49 +00:00
|
|
|
|
|
|
|
|
## 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.
|
2020-08-12 14:54:56 +00:00
|
|
|
|
|
|
|
|
## 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.
|
