Overview

This page contains the list of deprecations and important or breaking changes for Vault 1.8.x compared to 1.7. Please read it carefully.

License enhancements

Licenses and EULA enhancements have been introduced in the Vault 1.8 release. These changes are important for Enterprise customers to review. They do not affect OSS users. Please see the License documentation for more details.

Deprecations

The following API endpoints have been deprecated and will be removed in a future release:

sys/license to manage licenses in storage; it is recommended to use License Autoloading instead.
/gcp/token/:roleset and /gcp/key/:roleset paths for generating secrets for rolesets in GCP Secrets. Use /gcp/roleset/:roleset/token and /gcp/roleset/:roleset/key instead.

Note: Policies containing globs should be avoided when giving users read access to /gcp/roleset to avoid giving users permissions to generate tokens.

Go version

Vault 1.8.0 is built with Go 1.16. Please review the Go Release Notes for full details. Of particular note:

Go 1.16 has added support for darwin/arm64. Vault binaries for this platform are now available supporting the Apple M1 CPU.

Alpine 3.14

Docker images for Vault 1.6.6+, 1.7.4+, and 1.8.2+ are built with Alpine 3.14, due to a security issue in Alpine 3.13 (CVE-2021-36159). Some users on older versions of Docker may run into issues with these images. See the following for more details:

Entity alias mapping

Previously, an entity in Vault could be mapped to multiple entity aliases on the same authentication backend. This led to a potential security vulnerability (CVE-2021-43998), as ACL policies templated with alias information would match the first alias created. Thus, tokens created from all aliases of the entity, will have access to the paths containing alias metadata of the first alias due to templated policies being incorrectly applied. As a result, the mapping behavior was updated such that an entity can only have one alias per authentication backend. This change exists in Vault 1.9.0+, 1.8.5+ and 1.7.6+.

PKI certificate generation forwarding regression

A bug introduced in Vault 1.8 causes certificate generation requests to the PKI secrets engine made on a performance secondary node to be forwarded to the cluster's primary node. The resulting certificates are stored on the primary node, and thus visible to list and read certificate requests only on the primary node rather than the secondary node as intended. Furthermore, if a certificate is subsequently revoked on a performance secondary node, the secondary's certificate revocation list is updated, rather than the primary's where the certificate is stored. This bug is fixed in Vault 1.8.8 and 1.9.3.
Certificates issued after the fix are correctly stored locally to the performance secondary.

Known issues

Raft in Vault uses its own set of TLS certificates, independent of those that the user controls to protect the API port and those used for replication and clustering. These certs get rotated daily, but to ensure that nodes which were down or behind on Raft log replication don't lose the ability to speak with other nodes, the newly generated daily TLS cert only starts being used once we see that all nodes have received it.

A recent security audit related change results in this rotation code getting a panic when the current cert is more than 24h old. This can happen if the cluster as a whole is down for a day or more. It can also happen if a single node is unreachable 24h, or sufficiently backlogged in applying raft logs that it's more than a day behind.

Impacted versions: 1.10.1, 1.9.5, 1.8.10. Versions prior to these are unaffected.

New releases addressing this panic are coming soon.

MSSQL integrations

MSSQL integrations (storage and secrets engine) will crash with a "panic: not implemented" error (#12830). This affects Vault versions 1.8.0 and up. It will be fixed in the next minor update.

Vault enterprise binaries

Vault Enterprise binaries for arm64 architectures will crash immediately when using production-ready storage backends. This issue is addressed in Vault 1.8.1.

AWS auth

AWS Auth using the EC2 method fails with the error failed to verify the signature. This effects 1.8.0 and 1.8.1 and there is not a workaround. The issue was fixed in Vault 1.8.2.

Configuration files in RedHat packages

Configuration files in RedHat packages for Vault were not properly flagged as config files for fpm, causing user-edited files on disk to be replaced with the defaults when a new package was installed. This issue affects RedHat packages for Vault 1.8.0 and the 1.8.1-0 package, and is fixed in 1.8.1-1 and up.

Introduction of rolesets

The introduction of /gcp/roleset/:roleset/token and /gcp/roleset/:roleset/key could inadvertently give users the ability to generate tokens and key if globs are used in policies. To avoid issues like this, globs should be avoided in policies to help adhere to the principle of least privilege. See the roleset documentation for more information.