Overview
The Vault 1.17.x upgrade guide contains information on deprecations, important or breaking changes, and remediation recommendations for anyone upgrading from Vault 1.16. Please read carefully.
Important changes
Allowed audit headers now have unremovable defaults
The config auditing API endpoint tells Vault to log incoming request headers (when present) in the audit log.
Previously, Vault only logged headers that were explicitly configured for logging. As of version 1.17, Vault automatically logs a predefined set of default headers. By default, the header values are not HMAC encrypted. You must explicitly configure the HMAC setting for each of the default headers if required.
Refer to the audit request headers documentation for more information.
PKI sign-intermediate now truncates notAfter field to signing issuer
Prior to 1.17.x, Vault allowed the calculated sign-intermediate notAfter
field
to go beyond the signing issuer notAfter
field. The extended value lead to a
CA chain that would not validate properly. As of 1.17.x, Vault truncates the
intermediary notAfter
value to the signing issuer notAfter
if the calculated
field is greater.
How to opt out
You can use the new enforce_leaf_not_after_behavior
flag on the
sign-intermediate API along with the leaf_not_after_behavior
flag for the
signing issuer to opt out of the truncating behavior.
When you set enforce_leaf_not_after_behavior
to true, the sign-intermediate
API uses the leaf_not_after_behavior
value configured for the signing issuer
to control truncation the behavior. Setting the issuer leaf_not_after_behavior
field to permit
and enforce_leaf_not_after_behavior
to true restores the
legacy behavior.
Request limiter deprecation
Vault 1.16.0 included an experimental request limiter. The limiter was disabled by default. Further testing indicated that an alternative approach improves performance and reduces risk for many workloads. Vault 1.17.0 includes a new adaptive overload protection feature that prevents outages when Vault is overwhelmed by write requests. Adaptive overload protection is a beta feature in 1.17.0 and is disabled by default.
The beta request limiter will be removed from Vault entirely in a later release.
JWT auth login requires bound audiences on the role
The bound_audiences
parameter of "jwt" roles is mandatory if the JWT contains an audience
(which is more often than not the case), and must match at least one of
the JWT's associated aud
claims. The aud
claim claim can be a single string
or a list of strings as per RFC 7519 Section 4.1.3.
If the JWT's aud
claim is not set, then the role's bound_audiences
parameter is not required.
Users may not be able to log into Vault if the JWT role is configured incorrectly. For additional details, refer to the JWT auth method (API) documentation.
Known issues and workarounds
PKI OCSP GET requests can return HTTP redirect responses
If a base64 encoded OCSP request contains consecutive '/' characters, the GET request will return a 301 permanent redirect response. If the redirection is followed, the request will not decode as it will not be a properly base64 encoded request.
As a workaround, OCSP POST requests can be used which are unaffected.
Impacted versions
Affects all current versions of 1.12.x, 1.13.x, 1.14.x, 1.15.x, 1.16.x, 1.17.x.
Vault Agent and Vault Proxy consume an excessive amount of CPU
Vault Agent and Vault Proxy consume an exessive amount of CPU during normal operation in 1.17.0.
We recommend waiting until 1.17.1 to upgrade Agent and Proxy.
Impacted versions
Affects 1.17.0.
Potential DoS when using the deny_unauthorized
proxy protocol behavior for a TCP listener
Affected versions
Community Edition (CE)
- 1.10.x - 1.15.x
- 1.17.1
Enterprise
- 1.10.x+ent - 1.15.11+ent
- 1.16.5+ent
- 1.17.1+ent
Issue
Vault TCP listeners configured with the deny_unauthorized
proxy_protocol_behavior
close if they receive a request from an untrusted upstream connection. As a result,
Vault no longer responds to any request received through that listener.
Being able to force-close listeners with intentionally untrusted connections leaves the Vault API vulnerable to a denial-of-service (DoS) attacks, which could cause the API to become unavailable on that node.
The vulnerability is addressed in Vault 1.15.12+ent, 1.16.6+ent, 1.17.2, 1.17.2+ent and later.
Workaround
Do not configure a proxy_protocol_behavior
with the deny_unauthorized
value.
Input data on Transit Generate CMAC Response
CMAC support in the Transit engine has a known issue that causes it to return the original input along with the computed CMAC value in the CMAC field of the response.
We recommend waiting until version 1.17.2+ent for using this feature.
Impacted versions
Affects 1.17.0+ent and1.17.1+ent.