This page contains the list of deprecations and important or breaking changes for Vault 0.9.0 compared to the most recent release. Please read it carefully.
pki/root/generate when a CA cert/key already exists will now return a
204 instead of overwriting an existing root. If you want to recreate the
root, first run a delete operation on
then generate it again.
In prior versions of Vault, if authenticating via AWS IAM and requesting a periodic token, the period was not properly respected. This could lead to tokens expiring unexpectedly, or a token lifetime being longer than expected. Upon token renewal with Vault 0.8.2 the period will be properly enforced.
vault ssh users should supply
-role to reduce the number of API
calls. A future version of Vault will mark these optional values are required.
Failure to supply
-role will result in a warning.
Vault plugins will first briefly run a restricted version of the plugin to fetch metadata, and then lazy-load the plugin on first request to prevent crash/deadlock of Vault during the unseal process. Plugins will need to be built with the latest changes in order for them to run properly.
For all built-in authentication backends, policies can now be specified as a
comma-delimited string or an array if using JSON as API input; on read,
policies will be returned as an array; and the
default policy will not be
forcefully added to policies saved in configurations. Please note that the
default policy will continue to be added to generated tokens, however, rather
than backends adding
default to the given set of input policies (in some
cases, and not in others), the stored set will reflect the user-specified set.
In 0.8.2 the endpoint would not modify the Issuer in the generated certificate,
leaving the output self-issued. Although theoretically valid, in practice
crypto stacks were unhappy validating paths containing such certs. As a result,
sign-self-issued now encodes the signing CA's Subject DN into the Issuer DN
of the generated certificate.
sys/raw endpoint can be extremely useful in break-glass or support
scenarios, it is also extremely dangerous. As of now, a configuration file
raw_storage_endpoint must be set in order to enable this API endpoint.
Once set, the available functionality has been enhanced slightly; it now
supports listing and decrypting most of Vault's core data structures, except
for the encryption keyring itself.
To better reflect its actual use, the
generic backend is now
generic will still work for backwards compatibility.
When using Vault with an HSM, a new parameter is required:
This performs a similar function to
key_label but for the HMAC key Vault will
use. Vault will generate a suitable key if this value is specified and
generate_key is set true. See the seal configuration page for
NewClient the API no longer modifies the provided
client/transport. In particular this means it will no longer enable redirection
limiting and HTTP/2 support on custom clients. It is suggested that if you want
to make changes to an HTTP client that you use one created by
as a starting point.
The client nonce generated by the backend that gets returned along with the authentication response will be audited in plaintext. If this is undesired, the clients can choose to supply a custom nonce to the login endpoint. The custom nonce set by the client will from now on, not be returned back with the authentication response, and hence not audit logged.
The API will now error when trying to create or update a role with the
When reading back a role from the
ssh backend, the TTL/max TTL values will
now be an integer number of seconds rather than a string. This better matches
the API elsewhere in Vault.
When listing roles from the
ssh backend via the API, the response data will
additionally return a
key_info map that will contain a map of each key with a
corresponding object containing the
Audit request and response entries are still in RFC3339 format but now have a granularity of nanoseconds.