Overview

The Vault 1.15.x upgrade guide contains information on deprecations, important or breaking changes, and remediation recommendations for anyone upgrading from Vault 1.14. Please read carefully.

Consul service registration

As of version 1.15, service_tags supplied to Vault for the purpose of Consul service registration will be case-sensitive.

In previous versions of Vault tags were converted to lowercase which led to issues, for example when tags contained Traefik rules which use case-sensitive method names such as Host().

If you previously used Consul service registration tags ignoring case, or relied on the lowercase tags created by Vault, then this change may cause unexpected behavior.

Please audit your Consul storage stanza to ensure that you either:

• Manually convert your service_tags to lowercase if required
• Ensure that any system that relies on the tags is aware of the new case-preserving behavior

Rollback metrics

Vault no longer measures and reports the metrics vault.rollback.attempts.{MOUNTPOINT} and vault.route.rollback.{MOUNTPOINT} by default. The new default metrics are vault.rollback.attempts and vault.route.rollback, which do not contain the mount point in the metric name.

To continue measuring vault.rollback.attempts.{MOUNTPOINT} and vault.route.rollback.{MOUNTPOINT}, you must explicitly enable mount-specific metrics in the telemetry stanza of your Vault configuration with the add_mount_point_rollback_metrics option.

Application of Sentinel Role Governing Policies (RGPs) via identity groups

As of versions 1.15.0, 1.14.4, and 1.13.8, the Sentinel RGPSs derived from membership in identity groups apply only to entities in the same and child namespaces, relative to the identity group.

Also, the group_policy_application_mode only applies to to ACL policies. Vault Sentinel Role Governing Policies (RGPs) are not affected by group policy application mode.

Known issues and workarounds

Transit Encryption with Cloud KMS managed keys causes a panic

Affected versions

• 1.13.1+ up to 1.13.8 inclusively
• 1.14.0+ up to 1.14.4 inclusively
• 1.15.0

Issue

Vault panics when it receives a Transit encryption API call that is backed by a Cloud KMS managed key (Azure, GCP, AWS).

Workaround

None at this time

Transit Sign API calls with managed keys fail

Affected versions

• 1.14.0+ up to 1.14.4 inclusively
• 1.15.0

Issue

Vault responds to Transit sign API calls with the following error when the request uses a managed key:

requested version for signing does not contain a private part

Workaround

None at this time

Panic in AWS auth method during IAM-based login

Affected versions

• 1.15.0

Issue

A panic can occur in the AWS auth method during IAM-based login when a client config does not exist.

Workaround

The panic can be avoided by writing an empty client config:

vault write -f auth/aws/config/client

Collapsed navbar does not allow you to click inside the console or namespace picker

Affected versions

The UI issue affects Vault versions 1.14.0+ and 1.15.0+. A fix is expected for Vault 1.16.0.

Issue

The Vauil UI currently uses a version of HDS that does not allow users to click within collapsed elements. In particular, the dev console or namespace picker become inaccessible when viewing the components in smaller viewports.

Workaround

Expand the width of the screen until you deactivate the collapsed view. Once the full navbar is displayed, click the desired components.

File audit devices do not honor SIGHUP signal to reload

Affected versions

• 1.15.0

Issue

The new underlying event framework for auditing causes Vault to continue using audit log files instead of reopening the file paths even when you send SIGHUP after log rotation. The issue impacts any Vault cluster with file audit devices enabled.

Not honoring the SIGHUP signal has two key consequences when moving or deleting audit files.

If you move or rename your audit log file locally, Vault continues to log data to the original file. For example, if you archive a file locally:

$ mv /var/log/vault/audit.log /var/log/vault/archive/audit.log.bak

Vault continues to write data to /var/log/vault/archive/audit.log.bak instead of logging audit entries to a newly created file at /var/log/vault/audit.log.

If you delete your audit log file, the OS unlinks the file from the directory structure, but Vault still has the file open. Vault continues to write data to the deleted file, which continues to consume disk space as it grows. When Vault is sealed or restarted, the OS deletes the previously unlinked file, and you will lose all data logged to the audit file after it was tagged for deletion.

The issue with file audit devices not honoring SIGHUP signals is fixed as a patch release in Vault 1.15.1.

Workaround

Set the VAULT_AUDIT_DISABLE_EVENTLOGGER environment variable to true to disable the new underlying event framework and restart Vault:

$ export VAULT_AUDIT_DISABLE_EVENTLOGGER=true

On startup, Vault reverts to the audit behavior used in 1.14.x.