Vault
Important changes
Always review important or breaking changes and remediation recommendations before upgrading Vault.
Transit support for Ed25519ph and Ed25519ctx signatures
Change | Affected version | Affected deployments |
---|---|---|
New behavior | 1.19.0 | Transit plugins using Ed25519 keys |
Prior versions of sign and verify API endpoints backed by an Ed25519 key ignored
prehashed=true
or hash_algorithm=sha2-512
parameters. As a result, the
endpoint always returned or verified a Pure Ed25519 signature.
The Transit plugin now assumes input hashed using the SHA-512 algorithm and
returns an Ed25519ph or Pure Ed25519 signature based on the configuration of
prehashed
and hash_algorithm
parameters:
Vault edition | prehashed | hash_algorithm | Return value |
---|---|---|---|
Enterprise | not set | not set | Pure Ed25519 |
Enterprise | false | any value other than sha2-512 | Pure Ed25519 |
Enterprise | false | sha2-512 | Error |
Enterprise | true | any value other than sha2-512 | Error |
Enterprise | true | sha2-512 | Ed25519ph |
CE | not set | not set | Pure Ed25519 |
CE | false | any value other than sha2-512 | Pure Ed25519 |
CE | false | sha2-512 | Error |
CE | true | any value other than sha2-512 | Error |
CE | true | sha2-512 | Error |
Identity system duplicate cleanup Enterprise
Change | Affected version | Affected deployments |
---|---|---|
New behavior | 1.19.0 | any |
Vault 1.19.0 includes a feature flag that, when enabled, forces deduplication of existing identities and forbids duplicate identities going forward. Once activated, the deduplication feature corrects historical identity bugs with a one-time deduplication process and restores Vault to secure, default behavior.
Vault does not enforce deduplication until you activate the relevant feature flag.
Recommendation
Vault 1.19.0 also includes improved reporting in server logs to help diagnose whether you have duplicate identities in your Vault instance.
After upgrading, review your server logs for identity duplicate reporting.
refer to the resolve duplicate identities guides to understand deduplication log messages, determine if you need to take action, make the necessary updates, and ensure the forced deduplication process resolves safely.
LDAP user DN search with upndomain
((#ldap))
Change | Affected version | Affected deployments |
---|---|---|
Breaking | 1.19.x | any |
Security improvements to
hashicorp/cap/ldap
ensure
that user DN searches with upndomain
configured return an error if the search
returns more than one result.
Recommendation
In previous Vault versions, DN searches with upndomain
configured returned the
last user found for searches with multiple results. Review and update any code
that performs DN searches to handle multi-result errors and/or revise the search
to ensure a single result.
Refer to the Github PR for more details.
Duplicate unseal/seal wrap HSM keys Enterprise
Change | Affected version | Affected deployments |
---|---|---|
Known issue | 1.19.x, 1.18.x, 1.17.x, 1.16.x | HSM-HA configurations migrating from Shamir to HSM-backed unseal/seal wraps. |
Vault may create duplicate HSM keys when you migrate from Shamir to an HSM-backed unseal configuration for high availability (HA) HSM deployments. Key duplication can happen even after a seal migration to HSM that initially appears successful.
Duplicate HSM keys can cause the following errors:
- intermittent read failures with errors such as
CKR_SIGNATURE_INVALID
andCKR_KEY_HANDLE_INVALID
for seal-wrapped values. - nodes fail to unseal after a restart with errors such as
CKR_DATA_INVALID
.
Recommendation
Always run Vault with generate_key = false
and manually create all required
keys within the HSM during the setup process.
Anonymized cluster data returned with license utilization Enterprise
Change | Affected version | Affected deployments |
---|---|---|
New behavior | 1.19.0 | any |
As of version 1.19.0 Vault Enterprise collects anonymous usage data about the running Vault cluster and automatically sends the cluster usage data along with the standard utilization data currently reported through automated license reporting.
RADIUS authentication is no longer case sensitive
Change | Affected version | Affected deployments |
---|---|---|
New behavior | 1.19.0 | any |
As of Vault 1.19.0 the RADIUS authentication plugin does not enforce case sensitivity on entered credentials.
Login/token renewal failures after group changes
Change | Affected version | Affected deployments |
---|---|---|
Known issue | 1.19.0 | any |
Performance standby nodes cannot persist updated group membership to storage.
As a result, standby nodes return a 500
error during login or token renewal if
the external group associated with the client entity changes.
Recommendation
Direct all logins and token renewals to the active/primary node.
Strict validation for Azure auth login requests
Change | Affected version | Affected deployments |
---|---|---|
New behavior | 1.19.1, 1.18.7, 1.17.14, 1.16.18 | any |
Azure auth plugin requires resource_group_name
, vm_name
, and vmss_name
to match the JWT claims on login
Vault versions before 1.19.1, 1.18.7, 1.17.14, and 1.16.18 did not strictly
validate the resource_group_name
, vm_name
, and vmss_name
parameters
against their token claims for clients logging in with Azure authentication.
Recommendation
Review the Token validation section of the Azure authN plugin guide for more information on the new validation requirements.
Static LDAP role rotations on upgrade
Change | Affected version | Affected deployments |
---|---|---|
Known issue | 1.19.0 - 1.19.1, 1.18.5 - 1.18.7, 1.17.12 - 1.17.14, 1.16.16 - 1.16.18 | any |
Vault automatically rotates existing static roles tied to LDAP credentials once when upgrading to an affected version. After the one-time rotation, the static roles behave as expected.
Recommendation
If you rely on LDAP static roles, upgrade to Vault 1.19.2+, 1.18.8+, 1.17.15+, or 1.16.19+.
Static DB role rotations on upgrade
Change | Affected version | Affected deployments |
---|---|---|
Known issue | 1.14.x or earlier | any |
When upgrading from Vault version 1.14.x or earlier, Vault automatically rotates existing static roles tied to database credentials once when upgrading to an affected version. After the one-time rotation, the static roles behave as expected.
Recommendation
If you rely on database static roles, avoid directly upgrading to the following Vault versions:
- 1.19.0 - 1.19.2
- 1.18.5 - 1.18.8
- 1.17.12 - 1.17.15
- 1.16.16 - 1.16.19
Vault log file missing subsystem logs
Change | Affected version | Affected deployments |
---|---|---|
Bug | 1.16.0, 1.17.13, 1.18.6, 1.19.0 | any |
Log entries, including plugin logs, for Vault deployments using log_file
do
not capture all relevant information even though the information appears as
expected in standard error and standard output.
Recommendation
Upgrade to one of the following Vault versions: 1.16.1+, 1.17.14+, 1.18.7+, 1.19.1+
Automated rotation stops after unseal
Change | Affected version | Affected deployments |
---|---|---|
Bug | 1.19.0 - 1.19.2 | any |
After unsealing Vault, the rotation manager does not reinstate the rotation queue. The stopped queue then causes automated root credential rotations to stop.
Recommendation
Update the root configuration on affected backends to recreate the rotation schedule with the previous values.
$ vault write aws/config/root \
rotation_schedule="<old_schedule>" \
rotation_window="<old_window>"
Azure Auth fails to authenticate Uniform VMSS instances
Change | Affected version | Affected deployments |
---|---|---|
Bug | 1.16.18+, 1.17.14+, 1.18.7+, 1.19.1+ | any |
A previous update to validate JWT claims against the provided VM, VMSS, and resource group names without accounting for the uniform VMSS format introduced a regression that causes Azure authentication from a uniform VMSS instance with a user assigned managed identity on the VMSS to incorrectly return an error.
Recommendation
Avoid upgrading until we fix the issue.