vault for anyone upgrading to 1 16 x from Vault 1 15 x Deprecations important or breaking changes and remediation recommendations layout docs page title Upgrade to Vault 1 16 x Guides Overview

Answer:
---
layout: docs
page_title: Upgrade to Vault 1.16.x - Guides
description: |-
  Deprecations, important or breaking changes, and remediation recommendations
  for anyone upgrading to 1.16.x from Vault 1.15.x.
---

# Overview

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

## Important changes

### External plugin variables take precedence over system variables ((#external-plugin-variables))

Vault gives precedence to plugin environment variables over system environment
variables when loading external plugins. The behavior for builtin plugins and
plugins that do not specify additional environment variables is unaffected.

For example, if you register an external plugin with `SOURCE=child` in the
[env](/vault/api-docs/system/plugins-catalog#env) parameter but the main Vault
process already has `SOURCE=parent` defined, the plugin process starts
with `SOURCE=child`.

Refer to the [plugin management](/vault/docs/plugins/plugin-management) page for
more details on plugin environment variables.

<Highlight title="Avoid conflicts with containerized plugins">

  Containerized plugins do not inherit system-defined environment variables. As
  a result, containerized plugins cannot have conflicts with Vault environment
  variables.

</Highlight>

#### How to opt out

To opt out of the precedence change, set the
`VAULT_PLUGIN_USE_LEGACY_ENV_LAYERING` environment variable to `true` for the
main Vault process:

```shell-session
$ export VAULT_PLUGIN_USE_LEGACY_ENV_LAYERING=true
```

Setting `VAULT_PLUGIN_USE_LEGACY_ENV_LAYERING` to `true` tells Vault to:

1. prioritize environment variables from the Vault server environment whenever
   the system detects a variable conflict.
1. report on plugin variable conflicts during the unseal process by printing
   warnings for plugins with conflicting environment variables or logging an
   informational entry when there are no conflicts.

For example, assume you set `VAULT_PLUGIN_USE_LEGACY_ENV_LAYERING` to `true`
and have an environment variable `SOURCE=parent`.

If you register an external plugin called `myplugin` with `SOURCE=child`, the
plugin process starts with `SOURCE=parent` and Vault reports a conflict for
`myplugin`.

### LDAP auth login changes

Users cannot log in using LDAP unless the LDAP plugin is configured
with an `userdn` value scoped to an organization unit (OU) where the
user resides.

### LDAP auth entity alias names no longer include upndomain

The `userattr` field on the LDAP auth config is now used as the entity alias.
Prior to 1.16, the LDAP auth method would detect if `upndomain` was configured
on the mount and then use `<cn>@<upndomain>` as the entity alias value.

The consequence of not configuring this correctly means users may not have the
correct policies attached to their tokens when logging in.

#### How to opt out

To opt out of the entity alias change, update the `userattr` field on the config:

```
userattr="userprincipalname"
```

Refer to the [LDAP auth method (API)](/vault/api-docs/auth/ldap) page for
more details on the configuration.

### Secrets Sync now requires setting a one-time flag before use

To use the Secrets Sync feature, the feature must be activated with a new one-time
operation called an activation-flag. The feature is gated until a Vault operator
decides to trigger the flag. More information can be found in the
[secrets sync documentation](/vault/docs/sync#activating-the-feature).

### Activity Log Changes

#### Default Activity Log Querying Period

As of 1.16.13 and later, the field `default_report_months` can no longer be configured or read. Any previously set values
will be ignored by the system.

Attempts to modify `default_report_months` through the
[/sys/internal/counters/config](/vault/api-docs/system/internal-counters#update-the-client-count-configuration)
endpoint, will result in the following warning from Vault:

<CodeBlockConfig hideClipboard>

  ```shell-session

  WARNING! The following warnings were returned from Vault:

  * default_report_months is deprecated: defaulting to billing start time

  ```

</CodeBlockConfig>

The `current_billing_period` toggle for `/sys/internal/counters/activity` is also deprecated, as this will be set
true by default.

Attempts to set `current_billing_period` will result in the following warning from Vault:

<CodeBlockConfig hideClipboard>

  ```shell-session

  WARNING! The following warnings were returned from Vault:

  * current_billing_period is deprecated; unless otherwise specified, all requests will default to the current billing period

  ```

</CodeBlockConfig>

### Auto-rolled billing start date

As of 1.16.7 and later, the billing start date (license start date if not configured) automatically rolls over to the latest billing year at the end of the last cycle.

@include 'auto-roll-billing-start.mdx'

@include 'auto-roll-billing-start-example.mdx'

### Docker image no longer contains `curl`

As of 1.16.7 and later, the `curl` binary is no longer included in the published Docker container
images for Vault and Vault Enterprise. If your workflow depends on `curl` being available in the
container, consider one of the following strategies:

#### Create a wrapper container image

Use the HashiCorp image as a base image to create a new container image with `curl` installed.

```Dockerfile
FROM hashicorp/vault-enterprise
RUN apk add curl
```

**NOTE:** While this is the preferred option it will require managing your own registry and rebuilding new images.

#### Install it at runtime dynamically

When running the image as root (not recommended), you can install it at runtime dynamically by using the `apk` package manager:

```shell-session
docker exec <CONTAINER-ID> apk add curl
```
```shell-session
kubectl exec -ti <NAME> -- apk add curl
```

When running the image as non-root without privilege escalation (recommended) you can use existing
tools to install a static binary of `curl` into the `vault` users home directory:

```shell-session
docker exec <CONTAINER-ID> wget https://github.com/moparisthebest/static-curl/releases/latest/download/curl-amd64 -O /home/vault/curl && chmod +x /home/vault/curl
```
```shell-session
kubectl exec -ti <NAME> -- wget https://github.com/moparisthebest/static-curl/releases/latest/download/curl-amd64 -O /home/vault/curl && chmod +x /home/vault/curl
```

**NOTE:** When using this option you'll want to verify that the static binary comes from a trusted source.

### Product usage reporting

As of 1.16.13, Vault will collect anonymous product usage metrics for HashiCorp. This information will be collected
alongside client activity data, and will be sent automatically if automated reporting is configured, or added to manual
reports if manual reporting is preferred.

See the main page for [Vault product usage metrics reporting](/vault/docs/enterprise/license/product-usage-reporting) for
more details, and information about opt-out.

## Known issues and workarounds

@include 'known-issues/1_17_audit-log-hmac.mdx'

@include 'known-issues/1_16-jwt_auth_bound_audiences.mdx'

@include 'known-issues/1_16-jwt_auth_config.mdx'

@include 'known-issues/1_16-ldap_auth_login_anonymous_group_search.mdx'

@include 'known-issues/1_16-ldap_auth_login_missing_entity_alias.mdx'

@include 'known-issues/1_16-default-policy-needs-to-be-updated.mdx'

@include 'known-issues/1_16-default-lcq-pre-1_9-upgrade.mdx'

@include 'known-issues/ocsp-redirect.mdx'

@include 'known-issues/1_16_azure-secrets-engine-client-id.mdx'

@include 'known-issues/perf-standbys-revert-to-standby.mdx'

@include 'known-issues/1_13-reload-census-panic-standby.mdx'

@include 'known-issues/autopilot-upgrade-upgrade-version.mdx'

@include 'known-issues/1_16_secrets-sync-chroot-activation.mdx'

@include 'known-issues/config_listener_proxy_protocol_behavior_issue.mdx'

@include 'known-issues/dangling-entity-aliases-in-memory.mdx'

@include 'known-issues/duplicate-identity-groups.mdx'

@include 'known-issues/manual-entity-merge-does-not-persist.mdx'

@include 'known-issues/duplicate-hsm-key.mdx'

layout  docs page title  Upgrade to Vault 1 16 x   Guides description       Deprecations  important or breaking changes  and remediation recommendations   for anyone upgrading to 1 16 x from Vault 1 15 x         Overview  The Vault 1 16 x upgrade guide contains information on deprecations  important or breaking changes  and remediation recommendations for anyone upgrading from Vault 1 15    Please read carefully        Important changes      External plugin variables take precedence over system variables    external plugin variables    Vault gives precedence to plugin environment variables over system environment variables when loading external plugins  The behavior for builtin plugins and plugins that do not specify additional environment variables is unaffected   For example  if you register an external plugin with  SOURCE child  in the  env   vault api docs system plugins catalog env  parameter but the main Vault process already has  SOURCE parent  defined  the plugin process starts with  SOURCE child    Refer to the  plugin management   vault docs plugins plugin management  page for more details on plugin environment variables    Highlight title  Avoid conflicts with containerized plugins      Containerized plugins do not inherit system defined environment variables  As   a result  containerized plugins cannot have conflicts with Vault environment   variables     Highlight        How to opt out  To opt out of the precedence change  set the  VAULT PLUGIN USE LEGACY ENV LAYERING  environment variable to  true  for the main Vault process      shell session   export VAULT PLUGIN USE LEGACY ENV LAYERING true      Setting  VAULT PLUGIN USE LEGACY ENV LAYERING  to  true  tells Vault to   1  prioritize environment variables from the Vault server environment whenever    the system detects a variable conflict  1  report on plugin variable conflicts during the unseal process by printing    warnings for plugins with conflicting environment variables or logging an    informational entry when there are no conflicts   For example  assume you set  VAULT PLUGIN USE LEGACY ENV LAYERING  to  true  and have an environment variable  SOURCE parent    If you register an external plugin called  myplugin  with  SOURCE child   the plugin process starts with  SOURCE parent  and Vault reports a conflict for  myplugin        LDAP auth login changes  Users cannot log in using LDAP unless the LDAP plugin is configured with an  userdn  value scoped to an organization unit  OU  where the user resides       LDAP auth entity alias names no longer include upndomain  The  userattr  field on the LDAP auth config is now used as the entity alias  Prior to 1 16  the LDAP auth method would detect if  upndomain  was configured on the mount and then use   cn   upndomain   as the entity alias value   The consequence of not configuring this correctly means users may not have the correct policies attached to their tokens when logging in        How to opt out  To opt out of the entity alias change  update the  userattr  field on the config       userattr  userprincipalname       Refer to the  LDAP auth method  API    vault api docs auth ldap  page for more details on the configuration       Secrets Sync now requires setting a one time flag before use  To use the Secrets Sync feature  the feature must be activated with a new one time operation called an activation flag  The feature is gated until a Vault operator decides to trigger the flag  More information can be found in the  secrets sync documentation   vault docs sync activating the feature        Activity Log Changes       Default Activity Log Querying Period  As of 1 16 13 and later  the field  default report months  can no longer be configured or read  Any previously set values will be ignored by the system    Attempts to modify  default report months  through the   sys internal counters config   vault api docs system internal counters update the client count configuration  endpoint  will result in the following warning from Vault    CodeBlockConfig hideClipboard        shell session    WARNING  The following warnings were returned from Vault       default report months is deprecated  defaulting to billing start time            CodeBlockConfig    The  current billing period  toggle for   sys internal counters activity  is also deprecated  as this will be set true by default   Attempts to set  current billing period  will result in the following warning from Vault    CodeBlockConfig hideClipboard        shell session    WARNING  The following warnings were returned from Vault       current billing period is deprecated  unless otherwise specified  all requests will default to the current billing period            CodeBlockConfig       Auto rolled billing start date  As of 1 16 7 and later  the billing start date  license start date if not configured  automatically rolls over to the latest billing year at the end of the last cycle    include  auto roll billing start mdx    include  auto roll billing start example mdx       Docker image no longer contains  curl   As of 1 16 7 and later  the  curl  binary is no longer included in the published Docker container images for Vault and Vault Enterprise  If your workflow depends on  curl  being available in the container  consider one of the following strategies        Create a wrapper container image  Use the HashiCorp image as a base image to create a new container image with  curl  installed      Dockerfile FROM hashicorp vault enterprise RUN apk add curl        NOTE    While this is the preferred option it will require managing your own registry and rebuilding new images        Install it at runtime dynamically  When running the image as root  not recommended   you can install it at runtime dynamically by using the  apk  package manager      shell session docker exec  CONTAINER ID  apk add curl        shell session kubectl exec  ti  NAME     apk add curl      When running the image as non root without privilege escalation  recommended  you can use existing tools to install a static binary of  curl  into the  vault  users home directory      shell session docker exec  CONTAINER ID  wget https   github com moparisthebest static curl releases latest download curl amd64  O  home vault curl    chmod  x  home vault curl        shell session kubectl exec  ti  NAME     wget https   github com moparisthebest static curl releases latest download curl amd64  O  home vault curl    chmod  x  home vault curl        NOTE    When using this option you ll want to verify that the static binary comes from a trusted source       Product usage reporting  As of 1 16 13  Vault will collect anonymous product usage metrics for HashiCorp  This information will be collected alongside client activity data  and will be sent automatically if automated reporting is configured  or added to manual reports if manual reporting is preferred   See the main page for  Vault product usage metrics reporting   vault docs enterprise license product usage reporting  for more details  and information about opt out      Known issues and workarounds   include  known issues 1 17 audit log hmac mdx    include  known issues 1 16 jwt auth bound audiences mdx    include  known issues 1 16 jwt auth config mdx    include  known issues 1 16 ldap auth login anonymous group search mdx    include  known issues 1 16 ldap auth login missing entity alias mdx    include  known issues 1 16 default policy needs to be updated mdx    include  known issues 1 16 default lcq pre 1 9 upgrade mdx    include  known issues ocsp redirect mdx    include  known issues 1 16 azure secrets engine client id mdx    include  known issues perf standbys revert to standby mdx    include  known issues 1 13 reload census panic standby mdx    include  known issues autopilot upgrade upgrade version mdx    include  known issues 1 16 secrets sync chroot activation mdx    include  known issues config listener proxy protocol behavior issue mdx    include  known issues dangling entity aliases in memory mdx    include  known issues duplicate identity groups mdx    include  known issues manual entity merge does not persist mdx    include  known issues duplicate hsm key mdx


vault for anyone upgrading to 1 18 x from Vault 1 17 x Deprecations important or breaking changes and remediation recommendations layout docs Overview page title Upgrade to Vault 1 18 x Guides

Answer:
---
layout: docs
page_title: Upgrade to Vault 1.18.x - Guides
description: |-
  Deprecations, important or breaking changes, and remediation recommendations
  for anyone upgrading to 1.18.x from Vault 1.17.x.
---

# Overview

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

## Important changes

### Activity Log Changes

#### Default Activity Log Querying Period

The field `default_report_months` can no longer be configured or read. Any previously set values
will be ignored by the system.

Attempts to modify `default_report_months` through the
[/sys/internal/counters/config](/vault/api-docs/system/internal-counters#update-the-client-count-configuration)
endpoint, will result in the following warning from Vault:

<CodeBlockConfig hideClipboard>

```shell-session

WARNING! The following warnings were returned from Vault:

  * default_report_months is deprecated: defaulting to billing start time

```

</CodeBlockConfig>

The `current_billing_period` toggle for `/sys/internal/counters/activity` is also deprecated, as this will be set
true by default.

Attempts to set `current_billing_period` will result in the following warning from Vault:

<CodeBlockConfig hideClipboard>

```shell-session

WARNING! The following warnings were returned from Vault:

  * current_billing_period is deprecated; unless otherwise specified, all requests will default to the current billing period

```

</CodeBlockConfig>

### Docker image no longer contains `curl`

The `curl` binary is no longer included in the published Docker container images for Vault and Vault
Enterprise. If your workflow depends on `curl` being available in the container, consider one of the
following strategies:

#### Create a wrapper container image

Use the HashiCorp image as a base image to create a new container image with `curl` installed.

```Dockerfile
FROM hashicorp/vault-enterprise
RUN apk add curl
```

**NOTE:** While this is the preferred option it will require managing your own registry and rebuilding new images.

#### Install it at runtime dynamically

When running the image as root (not recommended), you can install it at runtime dynamically by using the `apk` package manager:

```shell-session
docker exec <CONTAINER-ID> apk add curl
```
```shell-session
kubectl exec -ti <NAME> -- apk add curl
```

When running the image as non-root without privilege escalation (recommended) you can use existing
tools to install a static binary of `curl` into the `vault` users home directory:

```shell-session
docker exec <CONTAINER-ID> wget https://github.com/moparisthebest/static-curl/releases/latest/download/curl-amd64 -O /home/vault/curl && chmod +x /home/vault/curl
```
```shell-session
kubectl exec -ti <NAME> -- wget https://github.com/moparisthebest/static-curl/releases/latest/download/curl-amd64 -O /home/vault/curl && chmod +x /home/vault/curl
```

**NOTE:** When using this option you'll want to verify that the static binary comes from a trusted source.

### Request limiter configuration removal

Vault 1.16.0 included an experimental request limiter. The limiter was disabled
by default with an opt-in `request_limiter` configuration.

Further testing indicated that an alternative approach improves performance and
reduces risk for many workloads. Vault 1.17.0 included a new [adaptive overload
protection](/vault/docs/concepts/adaptive-overload-protection) feature that
prevents outages when Vault is overwhelmed by write requests.

Adaptive overload protection was a beta feature in 1.17.0.

As of Vault 1.18.0, the adaptive overload protection feature for writes is
now GA and enabled by default for the integrated storage backend.

The beta `request_limiter` configuration stanza is officially removed in Vault 1.18.0.

Vault will output two types of warnings if the `request_limiter` stanza is
detected in your Vault config.

1. A UI warning message printed to `stderr`:

```text
WARNING: Request Limiter configuration is no longer supported; overriding server configuration to disable
```

2. A log line with level `WARN`, appearing in Vault's logs:

```text
... [WARN]  unknown or unsupported field request_limiter found in configuration at config.hcl:22:1
```

### Product usage reporting

As of 1.18.2, Vault will collect anonymous product usage metrics for HashiCorp. This information will be collected
alongside client activity data, and will be sent automatically if automated reporting is configured, or added to manual
reports if manual reporting is preferred.

See the main page for [Vault product usage metrics reporting](/vault/docs/enterprise/license/product-usage-reporting) for
more details, and information about opt-out.

## Known issues and workarounds

@include 'known-issues/duplicate-hsm-key.mdx'

layout  docs page title  Upgrade to Vault 1 18 x   Guides description       Deprecations  important or breaking changes  and remediation recommendations   for anyone upgrading to 1 18 x from Vault 1 17 x         Overview  The Vault 1 18 x upgrade guide contains information on deprecations  important or breaking changes  and remediation recommendations for anyone upgrading from Vault 1 17    Please read carefully        Important changes      Activity Log Changes       Default Activity Log Querying Period  The field  default report months  can no longer be configured or read  Any previously set values will be ignored by the system    Attempts to modify  default report months  through the   sys internal counters config   vault api docs system internal counters update the client count configuration  endpoint  will result in the following warning from Vault    CodeBlockConfig hideClipboard      shell session  WARNING  The following warnings were returned from Vault       default report months is deprecated  defaulting to billing start time          CodeBlockConfig    The  current billing period  toggle for   sys internal counters activity  is also deprecated  as this will be set true by default   Attempts to set  current billing period  will result in the following warning from Vault    CodeBlockConfig hideClipboard      shell session  WARNING  The following warnings were returned from Vault       current billing period is deprecated  unless otherwise specified  all requests will default to the current billing period          CodeBlockConfig       Docker image no longer contains  curl   The  curl  binary is no longer included in the published Docker container images for Vault and Vault Enterprise  If your workflow depends on  curl  being available in the container  consider one of the following strategies        Create a wrapper container image  Use the HashiCorp image as a base image to create a new container image with  curl  installed      Dockerfile FROM hashicorp vault enterprise RUN apk add curl        NOTE    While this is the preferred option it will require managing your own registry and rebuilding new images        Install it at runtime dynamically  When running the image as root  not recommended   you can install it at runtime dynamically by using the  apk  package manager      shell session docker exec  CONTAINER ID  apk add curl        shell session kubectl exec  ti  NAME     apk add curl      When running the image as non root without privilege escalation  recommended  you can use existing tools to install a static binary of  curl  into the  vault  users home directory      shell session docker exec  CONTAINER ID  wget https   github com moparisthebest static curl releases latest download curl amd64  O  home vault curl    chmod  x  home vault curl        shell session kubectl exec  ti  NAME     wget https   github com moparisthebest static curl releases latest download curl amd64  O  home vault curl    chmod  x  home vault curl        NOTE    When using this option you ll want to verify that the static binary comes from a trusted source       Request limiter configuration removal  Vault 1 16 0 included an experimental request limiter  The limiter was disabled by default with an opt in  request limiter  configuration   Further testing indicated that an alternative approach improves performance and reduces risk for many workloads  Vault 1 17 0 included a new  adaptive overload protection   vault docs concepts adaptive overload protection  feature that prevents outages when Vault is overwhelmed by write requests   Adaptive overload protection was a beta feature in 1 17 0   As of Vault 1 18 0  the adaptive overload protection feature for writes is now GA and enabled by default for the integrated storage backend   The beta  request limiter  configuration stanza is officially removed in Vault 1 18 0   Vault will output two types of warnings if the  request limiter  stanza is detected in your Vault config   1  A UI warning message printed to  stderr       text WARNING  Request Limiter configuration is no longer supported  overriding server configuration to disable      2  A log line with level  WARN   appearing in Vault s logs      text      WARN   unknown or unsupported field request limiter found in configuration at config hcl 22 1          Product usage reporting  As of 1 18 2  Vault will collect anonymous product usage metrics for HashiCorp  This information will be collected alongside client activity data  and will be sent automatically if automated reporting is configured  or added to manual reports if manual reporting is preferred   See the main page for  Vault product usage metrics reporting   vault docs enterprise license product usage reporting  for more details  and information about opt out      Known issues and workarounds   include  known issues duplicate hsm key mdx


vault This page contains the list of deprecations and important or breaking changes page title Upgrading to Vault 0 10 0 Guides for Vault 0 10 0 Please read it carefully layout docs Overview

Answer:
---
layout: docs
page_title: Upgrading to Vault 0.10.0 - Guides
description: |-
  This page contains the list of deprecations and important or breaking changes
  for Vault 0.10.0. Please read it carefully.
---

# Overview

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

## Changes since 0.9.6

### Database plugin compatibility

The database plugin interface was enhanced to support some additional
functionality related to root credential rotation and supporting templated
URL strings. The changes were made in a backwards-compatible way and all
builtin plugins were updated with the new features. Custom plugins not built
into Vault will need to be upgraded to support templated URL strings and
root rotation. Additionally, the Initialize method was deprecated in favor
of a new Init method that supports configuration modifications that occur in
the plugin back to the primary data store.

### Removal of returned secret information

For a long time Vault has returned configuration given to various secret
engines and auth methods with secret values (such as secret API keys or
passwords) still intact, and with a warning to the user on write that anyone
with read access could see the secret. This was mostly done to make it easy for
tools like Terraform to judge whether state had drifted. However, it also feels
quite un-Vault-y to do this and we've never felt very comfortable doing so. In
0.10 we have gone through and removed this behavior from the various backends;
fields which contained secret values are simply no longer returned on read. We
are working with the Terraform team to make changes to their provider to
accommodate this as best as possible, and users of other tools may have to make
adjustments, but in the end we felt that the ends did not justify the means and
we needed to prioritize security over operational convenience.

### LDAP auth method case sensitivity

We now treat usernames and groups configured locally for policy assignment in a
case insensitive fashion by default. Existing configurations will continue to
work as they do now; however, the next time a configuration is written
`case_sensitive_names` will need to be explicitly set to `true`.

### TTL handling moved to core

All lease TTL handling has been centralized within the core of Vault to ensure
consistency across all backends. Since this was previously delegated to
individual backends, there may be some slight differences in TTLs generated
from some backends.

### Default `secret/` mount is deprecated

In 0.12 we will stop mounting `secret/` by default at initialization time (it
will still be available in `dev` mode).

## Full list since 0.9.0

### Change to AWS role output

The AWS authentication backend now allows binds for inputs as either a
comma-delimited string or a string array. However, to keep consistency with
input and output, when reading a role the binds will now be returned as string
arrays rather than strings.

### Change to AWS IAM auth ARN prefix matching

In order to prefix-match IAM role and instance profile ARNs in AWS auth
backend, you now must explicitly opt-in by adding a `*` to the end of the ARN.
Existing configurations will be upgraded automatically, but when writing a new
role configuration the updated behavior will be used.

### Backwards compatible CLI changes

This upgrade guide is typically reserved for breaking changes, however it
is worth calling out that the CLI interface to Vault has been completely
revamped while maintaining backwards compatibility. This could lead to
potential confusion while browsing the latest version of the Vault
documentation on vaultproject.io.

All previous CLI commands should continue to work and are backwards
compatible in almost all cases.

Documentation for previous versions of Vault can be accessed using
the GitHub interface by browsing tags (eg [0.9.1 website tree](https://github.com/hashicorp/vault/tree/v0.9.1/website)) or by
[building the Vault website locally](https://github.com/hashicorp/vault/tree/v0.9.1/website#running-the-site-locally).

### `sys/health` DR secondary reporting

The `replication_dr_secondary` bool returned by `sys/health` could be
misleading since it would be `false` both when a cluster was not a DR secondary
but also when the node is a standby in the cluster and has not yet fully
received state from the active node. This could cause health checks on LBs to
decide that the node was acceptable for traffic even though DR secondaries
cannot handle normal Vault traffic. (In other words, the bool could only convey
"yes" or "no" but not "not sure yet".) This has been replaced by
`replication_dr_mode` and `replication_perf_mode` which are string values that
convey the current state of the node; a value of `disabled` indicates that
replication is disabled or the state is still being discovered. As a result, an
LB check can positively verify that the node is both not `disabled` and is not
a DR secondary, and avoid sending traffic to it if either is true.

### PKI secret backend roles parameter types

For `ou` and `organization` in role definitions in the PKI secret backend,
input can now be a comma-separated string or an array of strings. Reading a
role will now return arrays for these parameters.

### Plugin API changes

The plugin API has been updated to utilize golang's context.Context package.
Many function signatures now accept a context object as the first parameter.
Existing plugins will need to pull in the latest Vault code and update their
function signatures to begin using context and the new gRPC transport.

### AppRole case sensitivity

In prior versions of Vault, `list` operations against AppRole roles would
require preserving case in the role name, even though most other operations
within AppRole are case-insensitive with respect to the role name. This has
been fixed; existing roles will behave as they have in the past, but new roles
will act case-insensitively in these cases.

### Token auth backend roles parameter types

For `allowed_policies` and `disallowed_policies` in role definitions in the
token auth backend, input can now be a comma-separated string or an array of
strings. Reading a role will now return arrays for these parameters.

### Transit key exporting

You can now mark a key in the `transit` backend as `exportable` at any time,
rather than just at creation time; however, once this value is set, it still
cannot be unset.

### PKI secret backend roles parameter types

For `allowed_domains` and `key_usage` in role definitions in the PKI secret
backend, input can now be a comma-separated string or an array of strings.
Reading a role will now return arrays for these parameters.

### SSH dynamic keys method defaults to 2048-bit keys

When using the dynamic key method in the SSH backend, the default is now to use
2048-bit keys if no specific key bit size is specified.

### Consul secret backend lease handling

The `consul` secret backend can now accept both strings and integer numbers of
seconds for its lease value. The value returned on a role read will be an
integer number of seconds instead of a human-friendly string.

### Unprintable characters not allowed in API paths

Unprintable characters are no longer allowed in names in the API (paths and
path parameters), with an extra restriction on whitespace characters. Allowed
characters are those that are considered printable by Unicode plus spaces.

layout  docs page title  Upgrading to Vault 0 10 0   Guides description       This page contains the list of deprecations and important or breaking changes   for Vault 0 10 0  Please read it carefully         Overview  This page contains the list of deprecations and important or breaking changes for Vault 0 10 0 compared to 0 9 0  Please read it carefully      Changes since 0 9 6      Database plugin compatibility  The database plugin interface was enhanced to support some additional functionality related to root credential rotation and supporting templated URL strings  The changes were made in a backwards compatible way and all builtin plugins were updated with the new features  Custom plugins not built into Vault will need to be upgraded to support templated URL strings and root rotation  Additionally  the Initialize method was deprecated in favor of a new Init method that supports configuration modifications that occur in the plugin back to the primary data store       Removal of returned secret information  For a long time Vault has returned configuration given to various secret engines and auth methods with secret values  such as secret API keys or passwords  still intact  and with a warning to the user on write that anyone with read access could see the secret  This was mostly done to make it easy for tools like Terraform to judge whether state had drifted  However  it also feels quite un Vault y to do this and we ve never felt very comfortable doing so  In 0 10 we have gone through and removed this behavior from the various backends  fields which contained secret values are simply no longer returned on read  We are working with the Terraform team to make changes to their provider to accommodate this as best as possible  and users of other tools may have to make adjustments  but in the end we felt that the ends did not justify the means and we needed to prioritize security over operational convenience       LDAP auth method case sensitivity  We now treat usernames and groups configured locally for policy assignment in a case insensitive fashion by default  Existing configurations will continue to work as they do now  however  the next time a configuration is written  case sensitive names  will need to be explicitly set to  true        TTL handling moved to core  All lease TTL handling has been centralized within the core of Vault to ensure consistency across all backends  Since this was previously delegated to individual backends  there may be some slight differences in TTLs generated from some backends       Default  secret   mount is deprecated  In 0 12 we will stop mounting  secret   by default at initialization time  it will still be available in  dev  mode       Full list since 0 9 0      Change to AWS role output  The AWS authentication backend now allows binds for inputs as either a comma delimited string or a string array  However  to keep consistency with input and output  when reading a role the binds will now be returned as string arrays rather than strings       Change to AWS IAM auth ARN prefix matching  In order to prefix match IAM role and instance profile ARNs in AWS auth backend  you now must explicitly opt in by adding a     to the end of the ARN  Existing configurations will be upgraded automatically  but when writing a new role configuration the updated behavior will be used       Backwards compatible CLI changes  This upgrade guide is typically reserved for breaking changes  however it is worth calling out that the CLI interface to Vault has been completely revamped while maintaining backwards compatibility  This could lead to potential confusion while browsing the latest version of the Vault documentation on vaultproject io   All previous CLI commands should continue to work and are backwards compatible in almost all cases   Documentation for previous versions of Vault can be accessed using the GitHub interface by browsing tags  eg  0 9 1 website tree  https   github com hashicorp vault tree v0 9 1 website   or by  building the Vault website locally  https   github com hashicorp vault tree v0 9 1 website running the site locally         sys health  DR secondary reporting  The  replication dr secondary  bool returned by  sys health  could be misleading since it would be  false  both when a cluster was not a DR secondary but also when the node is a standby in the cluster and has not yet fully received state from the active node  This could cause health checks on LBs to decide that the node was acceptable for traffic even though DR secondaries cannot handle normal Vault traffic   In other words  the bool could only convey  yes  or  no  but not  not sure yet    This has been replaced by  replication dr mode  and  replication perf mode  which are string values that convey the current state of the node  a value of  disabled  indicates that replication is disabled or the state is still being discovered  As a result  an LB check can positively verify that the node is both not  disabled  and is not a DR secondary  and avoid sending traffic to it if either is true       PKI secret backend roles parameter types  For  ou  and  organization  in role definitions in the PKI secret backend  input can now be a comma separated string or an array of strings  Reading a role will now return arrays for these parameters       Plugin API changes  The plugin API has been updated to utilize golang s context Context package  Many function signatures now accept a context object as the first parameter  Existing plugins will need to pull in the latest Vault code and update their function signatures to begin using context and the new gRPC transport       AppRole case sensitivity  In prior versions of Vault   list  operations against AppRole roles would require preserving case in the role name  even though most other operations within AppRole are case insensitive with respect to the role name  This has been fixed  existing roles will behave as they have in the past  but new roles will act case insensitively in these cases       Token auth backend roles parameter types  For  allowed policies  and  disallowed policies  in role definitions in the token auth backend  input can now be a comma separated string or an array of strings  Reading a role will now return arrays for these parameters       Transit key exporting  You can now mark a key in the  transit  backend as  exportable  at any time  rather than just at creation time  however  once this value is set  it still cannot be unset       PKI secret backend roles parameter types  For  allowed domains  and  key usage  in role definitions in the PKI secret backend  input can now be a comma separated string or an array of strings  Reading a role will now return arrays for these parameters       SSH dynamic keys method defaults to 2048 bit keys  When using the dynamic key method in the SSH backend  the default is now to use 2048 bit keys if no specific key bit size is specified       Consul secret backend lease handling  The  consul  secret backend can now accept both strings and integer numbers of seconds for its lease value  The value returned on a role read will be an integer number of seconds instead of a human friendly string       Unprintable characters not allowed in API paths  Unprintable characters are no longer allowed in names in the API  paths and path parameters   with an extra restriction on whitespace characters  Allowed characters are those that are considered printable by Unicode plus spaces


vault This page contains the list of deprecations and important or breaking changes for Vault 1 2 0 Please read it carefully page title Upgrading to Vault 1 2 0 Guides layout docs Overview

Answer:
---
layout: docs
page_title: Upgrading to Vault 1.2.0 - Guides
description: |-
  This page contains the list of deprecations and important or breaking changes
  for Vault 1.2.0. Please read it carefully.
---

# Overview

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

## Known issues

### AppRole upgrade issue

Due to a bug, on upgrade AppRole roles cannot be read properly. If using AppRole, do not upgrade until this issue is fixed in 1.2.1.

## Changes/Deprecations

### Path character handling

Due to underlying changes in Go's runtime past version 1.11.5, Vault is now
stricter about what characters it will accept in path names. Whereas before it
would filter out unprintable characters (and this could be turned off), control
characters and other invalid characters are now rejected within Go's HTTP
library before the request is passed to Vault, and this cannot be disabled. To
continue using these (e.g. for already-written paths), they must be properly
percent-encoded (e.g. `\r` becomes `%0D`, `\x00` becomes `%00`, and so on).

### AWSKMS seal region

The user-configured regions on the AWSKMS seal stanza will now be preferred
over regions set in the enclosing environment.

### Audit logging of empty values

All values in audit logs now are omitted if they are empty. This helps reduce
the size of audit log entries by not reproducing keys in each entry that
commonly don't contain any value, which can help in cases where audit log
entries are above the maximum UDP packet size and others.

### Rollback logging

Rollback will no longer display log messages when it runs; it will only display
messages if an error occurs.

### Database plugins

Database plugins now default to 4 max open connections rather than 2. This
should be safe in nearly all cases and fixes some issues where a single
operation could fail with the default configuration because it needed three
connections just for that operation. However, this could result in an increase
in held open file descriptors for each database configuration, so ensure that
there is sufficient overhead.

### AppRole various changes

- AppRole uses new, common token fields for values that overlap with other auth
  methods. `period` and `policies` will continue to work, with priority being
  given to the `token_` prefixed versions of these fields, but the values for
  those will only be returned on read if they were set initially.
- `default` is no longer automatically added to policies after submission. It
  was a no-op anyways since Vault's core would always add it, and changing this
  behavior allows AppRole to support the new `token_no_default_policy`
  parameter
- The long-deprecated `bound_cidr_list` is no longer returned when reading a
  role.

### Token store roles changes

Token store roles use new, common token fields for the values that overlap with
other auth backends. `period`, `explicit_max_ttl`, and `bound_cidrs` will
continue to work, with priority being given to the `token_` prefixed versions
of those parameters. They will also be returned when doing a read on the role
if they were used to provide values initially; however, in Vault 1.4 if
`period` or `explicit_max_ttl` is zero they will no longer be returned.
(`explicit_max_ttl` was already not returned if empty.)

### Go API/SDK changes

Vault now uses Go's official dependency management system, Go Modules, to
manage dependencies. As a result to both reduce transitive dependencies for API
library users and plugin authors, and to work around various conflicts, we have
moved various helpers around, mostly under an `sdk/` submodule. A couple of
functions have also moved from plugin helper code to the `api/` submodule. If
you are a plugin author, take a look at some of our official plugins and the
paths they are importing for guidance.

### Change in LDAP group CN handling

A bug fix put in place in Vault 1.1.1 to allow group CNs to be found from an
LDAP server in lowercase `cn` as well as uppercase `CN` had an unintended
consequence. If prior to that a group used `cn`, as in `cn=foo,ou=bar` then the
group that would need to be put into place in the LDAP plugin to match against
policies is `cn=foo,ou=bar` since the CN would not be correctly found. After
the change, the CN was correctly found, but this would result in the group name
being parsed as `foo` and would not match groups using the full DN. In 1.1.5+,
there is a boolean config setting `use_pre111_group_cn_behavior` to allow
reverting to the old matching behavior; we also attempt to upgrade exiting
configs to have that defaulted to true.

### JWT/OIDC plugin

Logins of role_type "oidc" via the /login path are no longer allowed.

### ACL wildcards

New ordering put into place in Vault 1.1.1 defines which policy wins when there
are multiple inexact matches and at least one path contains `+`. `+*` is now
illegal in policy paths. The previous behavior simply selected any matching
segment-wildcard path that matched.

### Replication

Due to technical limitations, mounting and unmounting was not previously
possible from a performance secondary. These have been resolved, and these
operations may now be run from a performance secondary.

layout  docs page title  Upgrading to Vault 1 2 0   Guides description       This page contains the list of deprecations and important or breaking changes   for Vault 1 2 0  Please read it carefully         Overview  This page contains the list of deprecations and important or breaking changes for Vault 1 2 0 compared to 1 1 0  Please read it carefully      Known issues      AppRole upgrade issue  Due to a bug  on upgrade AppRole roles cannot be read properly  If using AppRole  do not upgrade until this issue is fixed in 1 2 1      Changes Deprecations      Path character handling  Due to underlying changes in Go s runtime past version 1 11 5  Vault is now stricter about what characters it will accept in path names  Whereas before it would filter out unprintable characters  and this could be turned off   control characters and other invalid characters are now rejected within Go s HTTP library before the request is passed to Vault  and this cannot be disabled  To continue using these  e g  for already written paths   they must be properly percent encoded  e g    r  becomes   0D     x00  becomes   00   and so on        AWSKMS seal region  The user configured regions on the AWSKMS seal stanza will now be preferred over regions set in the enclosing environment       Audit logging of empty values  All values in audit logs now are omitted if they are empty  This helps reduce the size of audit log entries by not reproducing keys in each entry that commonly don t contain any value  which can help in cases where audit log entries are above the maximum UDP packet size and others       Rollback logging  Rollback will no longer display log messages when it runs  it will only display messages if an error occurs       Database plugins  Database plugins now default to 4 max open connections rather than 2  This should be safe in nearly all cases and fixes some issues where a single operation could fail with the default configuration because it needed three connections just for that operation  However  this could result in an increase in held open file descriptors for each database configuration  so ensure that there is sufficient overhead       AppRole various changes    AppRole uses new  common token fields for values that overlap with other auth   methods   period  and  policies  will continue to work  with priority being   given to the  token   prefixed versions of these fields  but the values for   those will only be returned on read if they were set initially     default  is no longer automatically added to policies after submission  It   was a no op anyways since Vault s core would always add it  and changing this   behavior allows AppRole to support the new  token no default policy    parameter   The long deprecated  bound cidr list  is no longer returned when reading a   role       Token store roles changes  Token store roles use new  common token fields for the values that overlap with other auth backends   period    explicit max ttl   and  bound cidrs  will continue to work  with priority being given to the  token   prefixed versions of those parameters  They will also be returned when doing a read on the role if they were used to provide values initially  however  in Vault 1 4 if  period  or  explicit max ttl  is zero they will no longer be returned    explicit max ttl  was already not returned if empty        Go API SDK changes  Vault now uses Go s official dependency management system  Go Modules  to manage dependencies  As a result to both reduce transitive dependencies for API library users and plugin authors  and to work around various conflicts  we have moved various helpers around  mostly under an  sdk   submodule  A couple of functions have also moved from plugin helper code to the  api   submodule  If you are a plugin author  take a look at some of our official plugins and the paths they are importing for guidance       Change in LDAP group CN handling  A bug fix put in place in Vault 1 1 1 to allow group CNs to be found from an LDAP server in lowercase  cn  as well as uppercase  CN  had an unintended consequence  If prior to that a group used  cn   as in  cn foo ou bar  then the group that would need to be put into place in the LDAP plugin to match against policies is  cn foo ou bar  since the CN would not be correctly found  After the change  the CN was correctly found  but this would result in the group name being parsed as  foo  and would not match groups using the full DN  In 1 1 5   there is a boolean config setting  use pre111 group cn behavior  to allow reverting to the old matching behavior  we also attempt to upgrade exiting configs to have that defaulted to true       JWT OIDC plugin  Logins of role type  oidc  via the  login path are no longer allowed       ACL wildcards  New ordering put into place in Vault 1 1 1 defines which policy wins when there are multiple inexact matches and at least one path contains           is now illegal in policy paths  The previous behavior simply selected any matching segment wildcard path that matched       Replication  Due to technical limitations  mounting and unmounting was not previously possible from a performance secondary  These have been resolved  and these operations may now be run from a performance secondary


vault This page contains the list of breaking changes for Vault 0 6 1 Please read page title Upgrading to Vault 0 6 1 Guides it carefully layout docs Overview

Answer:
---
layout: docs
page_title: Upgrading to Vault 0.6.1 - Guides
description: |-
  This page contains the list of breaking changes for Vault 0.6.1. Please read
  it carefully.
---

# Overview

This page contains the list of breaking changes for Vault 0.6.1. Please read it
carefully.

## Standby nodes must be 0.6.1 as well

Once an active node is running 0.6.1, only standby nodes running 0.6.1+ will be
able to form an HA cluster. If following our [general upgrade
instructions](/vault/docs/upgrading) this will
not be an issue.

## Health endpoint status code changes

Prior to 0.6.1, the health endpoint would return a `500` (Internal Server
Error) for both a sealed and uninitialized state. In both states this was
confusing, since it was hard to tell, based on the status code, an actual
internal error from Vault from a Vault that was simply uninitialized or sealed,
not to mention differentiating between those two states.

In 0.6.1, a sealed Vault will return a `503` (Service Unavailable) status code.
As before, this can be adjusted with the `sealedcode` query parameter. An
uninitialized Vault will return a `501` (Not Implemented) status code. This can
be adjusted with the `uninitcode` query parameter.

This removes ambiguity/confusion and falls more in line with the intention of
each status code (including `500`).

## Root token creation restrictions

Root tokens (tokens with the `root` policy) can no longer be created except by
another root token or the
[`generate-root`](/vault/api-docs/system/generate-root)
endpoint or CLI command.

## PKI backend certificates will contain default key usages

Issued certificates from the `pki` backend against roles created or modified
after upgrading will contain a set of default key usages. This increases
compatibility with some software that requires strict adherence to RFCs, such
as OpenVPN.

This behavior is fully adjustable; see the [PKI backend
documentation](/vault/docs/secrets/pki) for
details.

## DynamoDB does not support HA by default

If using DynamoDB and want to use HA support, you will need to explicitly
enable it in Vault's configuration; see the
[documentation](/vault/docs/configuration#ha_storage)
for details.

If you are already using DynamoDB in an HA fashion and wish to keep doing so,
it is _very important_ that you set this option **before** upgrading your Vault
instances. Without doing so, each Vault instance will believe that it is
standalone and there could be consistency issues.

## LDAP auth method forgets bind password and insecure TLS settings

Due to a bug, these two settings are forgotten if they have been configured in
the LDAP backend prior to 0.6.1. If you are using these settings with LDAP,
please be sure to re-submit your LDAP configuration to Vault after the upgrade,
so ensure that you have a valid token to do so before upgrading if you are
relying on LDAP authentication for permissions to modify the backend itself.

## LDAP auth method does not search `memberOf`

The LDAP backend went from a model where all permutations of storing and
filtering groups were tried in all cases to one where specific filters are
defined by the administrator. This vastly increases overall directory
compatibility, especially with Active Directory when using nested groups, but
unfortunately has the side effect that `memberOf` is no longer searched for by
default, which is a breaking change for many existing setups.

`Scenario 2` in the [updated
documentation](/vault/docs/auth/ldap) shows an
example of configuring the backend to query `memberOf`. It is recommended that
a test Vault server be set up and that successful authentication can be
performed using the new configuration before upgrading a primary or production
Vault instance.

In addition, if LDAP is relied upon for authentication, operators should ensure
that they have valid tokens with policies allowing modification of LDAP
parameters before upgrading, so that once an upgrade is performed, the new
configuration can be specified successfully.

## App-ID is deprecated

With the addition of the new [AppRole
backend](/vault/docs/auth/approle), App-ID is
deprecated. There are no current plans to remove it, but we encourage using
AppRole whenever possible, as it offers enhanced functionality and can
accommodate many more types of authentication paradigms. App-ID will receive
security-related fixes only.

layout  docs page title  Upgrading to Vault 0 6 1   Guides description       This page contains the list of breaking changes for Vault 0 6 1  Please read   it carefully         Overview  This page contains the list of breaking changes for Vault 0 6 1  Please read it carefully      Standby nodes must be 0 6 1 as well  Once an active node is running 0 6 1  only standby nodes running 0 6 1  will be able to form an HA cluster  If following our  general upgrade instructions   vault docs upgrading  this will not be an issue      Health endpoint status code changes  Prior to 0 6 1  the health endpoint would return a  500   Internal Server Error  for both a sealed and uninitialized state  In both states this was confusing  since it was hard to tell  based on the status code  an actual internal error from Vault from a Vault that was simply uninitialized or sealed  not to mention differentiating between those two states   In 0 6 1  a sealed Vault will return a  503   Service Unavailable  status code  As before  this can be adjusted with the  sealedcode  query parameter  An uninitialized Vault will return a  501   Not Implemented  status code  This can be adjusted with the  uninitcode  query parameter   This removes ambiguity confusion and falls more in line with the intention of each status code  including  500        Root token creation restrictions  Root tokens  tokens with the  root  policy  can no longer be created except by another root token or the   generate root    vault api docs system generate root  endpoint or CLI command      PKI backend certificates will contain default key usages  Issued certificates from the  pki  backend against roles created or modified after upgrading will contain a set of default key usages  This increases compatibility with some software that requires strict adherence to RFCs  such as OpenVPN   This behavior is fully adjustable  see the  PKI backend documentation   vault docs secrets pki  for details      DynamoDB does not support HA by default  If using DynamoDB and want to use HA support  you will need to explicitly enable it in Vault s configuration  see the  documentation   vault docs configuration ha storage  for details   If you are already using DynamoDB in an HA fashion and wish to keep doing so  it is  very important  that you set this option   before   upgrading your Vault instances  Without doing so  each Vault instance will believe that it is standalone and there could be consistency issues      LDAP auth method forgets bind password and insecure TLS settings  Due to a bug  these two settings are forgotten if they have been configured in the LDAP backend prior to 0 6 1  If you are using these settings with LDAP  please be sure to re submit your LDAP configuration to Vault after the upgrade  so ensure that you have a valid token to do so before upgrading if you are relying on LDAP authentication for permissions to modify the backend itself      LDAP auth method does not search  memberOf   The LDAP backend went from a model where all permutations of storing and filtering groups were tried in all cases to one where specific filters are defined by the administrator  This vastly increases overall directory compatibility  especially with Active Directory when using nested groups  but unfortunately has the side effect that  memberOf  is no longer searched for by default  which is a breaking change for many existing setups    Scenario 2  in the  updated documentation   vault docs auth ldap  shows an example of configuring the backend to query  memberOf   It is recommended that a test Vault server be set up and that successful authentication can be performed using the new configuration before upgrading a primary or production Vault instance   In addition  if LDAP is relied upon for authentication  operators should ensure that they have valid tokens with policies allowing modification of LDAP parameters before upgrading  so that once an upgrade is performed  the new configuration can be specified successfully      App ID is deprecated  With the addition of the new  AppRole backend   vault docs auth approle   App ID is deprecated  There are no current plans to remove it  but we encourage using AppRole whenever possible  as it offers enhanced functionality and can accommodate many more types of authentication paradigms  App ID will receive security related fixes only


vault This page contains the list of deprecations and important or breaking changes for Vault 0 11 0 Please read it carefully page title Upgrading to Vault 0 11 0 Guides layout docs Overview

Answer:
---
layout: docs
page_title: Upgrading to Vault 0.11.0 - Guides
description: |-
  This page contains the list of deprecations and important or breaking changes
  for Vault 0.11.0. Please read it carefully.
---

# Overview

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

## Known issues

### Nomad integration

Users that integrate Vault with Nomad should hold off on upgrading. A modification to
Vault's API is causing a runtime issue with the Nomad to Vault integration.

### Minified JSON policies

Users that generate policies in minfied JSON may cause a parsing errors due to
a regression in the policy parser when it encounters repeating brackets. Although
HCL is the official language for policies in Vault, HCL is JSON compatible and JSON
should work in place of HCL. To work around this error, pretty print the JSON policies
or add spaces between repeating brackets. This regression will be addressed in
a future release.

### Common mount prefixes

Before running the upgrade, users should run `vault secrets list` and `vault auth list`
to check their mount table to ensure that mounts do not have common prefix "folders".
For example, if there is a mount with path `team1/` and a mount with path `team1/secrets`,
Vault will fail to unseal. Before upgrade, these mounts must be remounted at a path that
does not share a common prefix.

## Changes since 0.10.4

### Request timeouts

A default request timeout of 90s is now enforced. This setting can be
overwritten in the config file. If you anticipate requests taking longer than
90s this setting should be configured before upgrading.

### `sys/` top level injection

For the last two years for backwards compatibility data for various `sys/`
routes has been injected into both the Secret's Data map and into the top level
of the JSON response object. However, this has some subtle issues that pop up
from time to time and is becoming increasingly complicated to maintain, so it's
finally being removed.

### Path fallback for list operations

For a very long time Vault has automatically adjusted `list` operations to
always end in a `/`, as list operations operates on prefixes, so all list
operations by definition end with `/`. This was done server-side so affects all
clients. However, this has also led to a lot of confusion for users writing
policies that assume that the path that they use in the CLI is the path used
internally. Starting in 0.11, ACL policies gain a new fallback rule for
listing: they will use a matching path ending in `/` if available, but if not
found, they will look for the same path without a trailing `/`. This allows
putting `list` capabilities in the same path block as most other capabilities
for that path, while not providing any extra access if `list` wasn't actually
provided there.

### Performance standbys on by default

If your flavor/license of Vault Enterprise supports Performance Standbys, they
are on by default. You can disable this behavior per-node with the
`disable_performance_standby` configuration flag.

### AWS secret engine roles

Roles in the AWS Secret Engine were previously ambiguous. For example, if the
`arn` parameter had been specified, that could have been interpreted as the ARN
of an AWS IAM policy to attach to an IAM user or it could have been the ARN of
an AWS role to assume. Now, types are explicit, both in terms of what
credential type is being requested (e.g., an IAM User or an Assumed Role?) as
well as the parameters being sent to vault (e.g., the IAM policy document
attached to an IAM user or used during a GetFederationToken call). All
credential retrieval remains backwards compatible as does updating role data.
However, the data returned when reading role data is now different and
breaking, so anything which reads role data out of Vault will need to be
updated to handle the new role data format.

While creating/updating roles remains backwards compatible, the old parameters
are now considered deprecated. You should use the new parameters as documented
in the API docs.

As part of this, the `/aws/creds/` and `/aws/sts/` endpoints have been merged,
with the behavior only differing as specified below. The `/aws/sts/` endpoint
is considered deprecated and should only be used when needing backwards
compatibility.

All roles will be automatically updated to the new role format when accessed.
However, due to the way role data was previously being stored in Vault, it's
possible that invalid data was stored that both make the upgrade impossible as
well as would have made the role unable to retrieve credentials. In this
situation, the previous role data is returned in an `invalid_data` key so you
can inspect what used to be in the role and correct the role data if desired.
One consequence of the prior AWS role storage format is that a single Vault
role could have led to two different AWS credential types being retrieved when
a `policy` parameter was stored. In this case, these legacy roles will be
allowed to retrieve both IAM User and Federation Token credentials, with the
credential type depending on the path used to access it (IAM User if accessed
via the `/aws/creds/<role_name>` endpoint and Federation Token if accessed via
the `/aws/sts/<role_name>` endpoint).

## Full list since 0.10.0

### Revocations of dynamic secrets leases now asynchronous

Dynamic secret lease revocation are now queued/asynchronous rather
than synchronous. This allows Vault to take responsibility for revocation
even if the initial attempt fails. The previous synchronous behavior can be
attained via the `-sync` CLI flag or `sync` API parameter. When in
synchronous mode, if the operation results in failure it is up to the user
to retry.

### CLI retries

The CLI will no longer retry commands on 5xx errors. This was a
source of confusion to users as to why Vault would "hang" before returning a
5xx error. The Go API client still defaults to two retries.

### Identity entity alias metadata

You can no longer manually set metadata on
entity aliases. All alias data (except the canonical entity ID it refers to)
is intended to be managed by the plugin providing the alias information, so
allowing it to be set manually didn't make sense.

### Convergent encryption version 3

If you are using `transit`'s convergent encryption feature, which prior to this
release was at version 2, we recommend
[rotating](/vault/api-docs/secret/transit#rotate-key)
your encryption key (the new key will use version 3) and
[rewrapping](/vault/api-docs/secret/transit#rewrap-data)
your data to mitigate the chance of offline plaintext-confirmation attacks.

### PKI duration return types

The PKI backend now returns durations (e.g. when reading a role) as an integer
number of seconds instead of a Go-style string.

layout  docs page title  Upgrading to Vault 0 11 0   Guides description       This page contains the list of deprecations and important or breaking changes   for Vault 0 11 0  Please read it carefully         Overview  This page contains the list of deprecations and important or breaking changes for Vault 0 11 0 compared to 0 10 0  Please read it carefully      Known issues      Nomad integration  Users that integrate Vault with Nomad should hold off on upgrading  A modification to Vault s API is causing a runtime issue with the Nomad to Vault integration       Minified JSON policies  Users that generate policies in minfied JSON may cause a parsing errors due to a regression in the policy parser when it encounters repeating brackets  Although HCL is the official language for policies in Vault  HCL is JSON compatible and JSON should work in place of HCL  To work around this error  pretty print the JSON policies or add spaces between repeating brackets  This regression will be addressed in a future release       Common mount prefixes  Before running the upgrade  users should run  vault secrets list  and  vault auth list  to check their mount table to ensure that mounts do not have common prefix  folders   For example  if there is a mount with path  team1   and a mount with path  team1 secrets   Vault will fail to unseal  Before upgrade  these mounts must be remounted at a path that does not share a common prefix      Changes since 0 10 4      Request timeouts  A default request timeout of 90s is now enforced  This setting can be overwritten in the config file  If you anticipate requests taking longer than 90s this setting should be configured before upgrading        sys   top level injection  For the last two years for backwards compatibility data for various  sys   routes has been injected into both the Secret s Data map and into the top level of the JSON response object  However  this has some subtle issues that pop up from time to time and is becoming increasingly complicated to maintain  so it s finally being removed       Path fallback for list operations  For a very long time Vault has automatically adjusted  list  operations to always end in a      as list operations operates on prefixes  so all list operations by definition end with      This was done server side so affects all clients  However  this has also led to a lot of confusion for users writing policies that assume that the path that they use in the CLI is the path used internally  Starting in 0 11  ACL policies gain a new fallback rule for listing  they will use a matching path ending in     if available  but if not found  they will look for the same path without a trailing      This allows putting  list  capabilities in the same path block as most other capabilities for that path  while not providing any extra access if  list  wasn t actually provided there       Performance standbys on by default  If your flavor license of Vault Enterprise supports Performance Standbys  they are on by default  You can disable this behavior per node with the  disable performance standby  configuration flag       AWS secret engine roles  Roles in the AWS Secret Engine were previously ambiguous  For example  if the  arn  parameter had been specified  that could have been interpreted as the ARN of an AWS IAM policy to attach to an IAM user or it could have been the ARN of an AWS role to assume  Now  types are explicit  both in terms of what credential type is being requested  e g   an IAM User or an Assumed Role   as well as the parameters being sent to vault  e g   the IAM policy document attached to an IAM user or used during a GetFederationToken call   All credential retrieval remains backwards compatible as does updating role data  However  the data returned when reading role data is now different and breaking  so anything which reads role data out of Vault will need to be updated to handle the new role data format   While creating updating roles remains backwards compatible  the old parameters are now considered deprecated  You should use the new parameters as documented in the API docs   As part of this  the   aws creds   and   aws sts   endpoints have been merged  with the behavior only differing as specified below  The   aws sts   endpoint is considered deprecated and should only be used when needing backwards compatibility   All roles will be automatically updated to the new role format when accessed  However  due to the way role data was previously being stored in Vault  it s possible that invalid data was stored that both make the upgrade impossible as well as would have made the role unable to retrieve credentials  In this situation  the previous role data is returned in an  invalid data  key so you can inspect what used to be in the role and correct the role data if desired  One consequence of the prior AWS role storage format is that a single Vault role could have led to two different AWS credential types being retrieved when a  policy  parameter was stored  In this case  these legacy roles will be allowed to retrieve both IAM User and Federation Token credentials  with the credential type depending on the path used to access it  IAM User if accessed via the   aws creds  role name   endpoint and Federation Token if accessed via the   aws sts  role name   endpoint       Full list since 0 10 0      Revocations of dynamic secrets leases now asynchronous  Dynamic secret lease revocation are now queued asynchronous rather than synchronous  This allows Vault to take responsibility for revocation even if the initial attempt fails  The previous synchronous behavior can be attained via the   sync  CLI flag or  sync  API parameter  When in synchronous mode  if the operation results in failure it is up to the user to retry       CLI retries  The CLI will no longer retry commands on 5xx errors  This was a source of confusion to users as to why Vault would  hang  before returning a 5xx error  The Go API client still defaults to two retries       Identity entity alias metadata  You can no longer manually set metadata on entity aliases  All alias data  except the canonical entity ID it refers to  is intended to be managed by the plugin providing the alias information  so allowing it to be set manually didn t make sense       Convergent encryption version 3  If you are using  transit  s convergent encryption feature  which prior to this release was at version 2  we recommend  rotating   vault api docs secret transit rotate key  your encryption key  the new key will use version 3  and  rewrapping   vault api docs secret transit rewrap data  your data to mitigate the chance of offline plaintext confirmation attacks       PKI duration return types  The PKI backend now returns durations  e g  when reading a role  as an integer number of seconds instead of a Go style string


vault page title Vault HA upgrades without Autopilot Upgrade Automation Pre 1 11 Upgrade instructions for Vault HA Pre 1 11 or Vault without autopilot upgrade automation being enabled Be sure to read the Upgrading Vault Guides as well Vault HA upgrades without autopilot upgrade automation Pre 1 11 layout docs This is our recommended upgrade procedure if one of the following applies

Answer:
---
layout: docs
page_title: Vault HA upgrades without Autopilot Upgrade Automation (Pre 1.11)
description: |-
  Upgrade instructions for Vault HA Pre 1.11 or Vault without autopilot upgrade automation being enabled. Be sure to read the Upgrading-Vault Guides as well.
---

# Vault HA upgrades without autopilot upgrade automation (Pre 1.11)

This is our recommended upgrade procedure if **one** of the following applies:

- Running Vault version earlier than 1.11
- Opt-out the [Autopilot automated upgrade](/vault/docs/concepts/integrated-storage/autopilot#automated-upgrade) features with Vault 1.11 or later
- Running Vault with external storage backend such as Consul

You should consider how to apply the steps described in this document to your
particular setup since HA setups can differ on whether a load balancer is in
use, what addresses clients are being given to connect to Vault (standby +
leader, leader-only, or discovered via service discovery), etc.

If you are running on Vault 1.11+ with Integrated Storage and wish to enable the
Autopilot upgrade automation features, read to the [automated
upgrades](/vault/docs/concepts/integrated-storage/autopilot#automated-upgrades)
documentation for details and the [Automate Upgrades with Vault
Enterprise](/vault/tutorials/raft/raft-upgrade-automation) tutorial for
additional guidance.

## HA installations

Regardless of the method you use, do not fail over from a newer version of Vault
to an older version. Our suggested procedure is designed to prevent this.

Please note that Vault does not support true zero-downtime upgrades, but with
proper upgrade procedure the downtime should be very short (a few hundred
milliseconds to a second depending on how the speed of access to the storage
backend).

<Warning title="Important">

If you are currently running on Vault 1.11+ with Integrated Storage and have
chosen to opt-out the Autopilot automated upgrade features, please disable the
default automated upgrade migrations feature of the Vault. To disable this
feature, follow the [Automate Upgrades with Vault Enterprise Autopilot
configuration](/vault/tutorials/raft/raft-upgrade-automation#autopilot-configuration)
tutorial for more details. Without disabling this feature, you may run into Lost
Quorum issue as described in the [Quorum lost while upgrading the vault from
1.11.0 to later version of
it](https://support.hashicorp.com/hc/en-us/articles/7122445204755-Quorum-lost-while-upgrading-the-vault-from-1-11-0-to-later-version-of-it)
article.

</Warning>

Perform these steps on each standby:

1. Properly shut down Vault on the standby node via `SIGINT` or `SIGTERM`
2. Replace the Vault binary with the new version; ensure that `mlock()`
   capability is added to the new binary with
   [setcap](/vault/docs/configuration#disable_mlock)
3. Start the standby node
4. Unseal the standby node
5. Verify `vault status` shows correct Version and HA Mode is `standby`
6. Review the node's logs to ensure successful startup and unseal

At this point all standby nodes are upgraded and ready to take over. The
upgrade will not complete until one of the upgraded standby nodes takes over
active duty.

To complete the cluster upgrade:

1. Properly shut down the remaining (active) node via `SIGINT` or `SIGTERM`

   <Warning title="Important">

   DO NOT attempt to issue a [step-down](/vault/docs/commands/operator/step-down)
   operation at any time during the upgrade process.

   </Warning>

   <Note>

   It is important that you shut the node down properly.
   This will release the current leadership and the HA lock, allowing a standby
   node to take over with a very short delay.
   If you kill Vault without letting it release the lock, a standby node will
   not be able to take over until the lock's timeout period has expired. This
   is backend-specific but could be ten seconds or more.

   </Note>

2. Replace the Vault binary with the new version; ensure that `mlock()`
   capability is added to the new binary with
   [setcap](/vault/docs/configuration#disable_mlock)
3. Start the node
4. Unseal the node
5. Verify `vault status` shows correct Version and HA Mode is `standby`
6. Review the node's logs to ensure successful startup and unseal

Internal upgrade tasks will happen after one of the upgraded standby nodes
takes over active duty.

Be sure to also read and follow any instructions in the version-specific
upgrade notes.

## Enterprise replication installations

See the main [upgrading](/vault/docs/upgrading#enterprise-replication-installations) page.

layout  docs page title  Vault HA upgrades without Autopilot Upgrade Automation  Pre 1 11  description       Upgrade instructions for Vault HA Pre 1 11 or Vault without autopilot upgrade automation being enabled  Be sure to read the Upgrading Vault Guides as well         Vault HA upgrades without autopilot upgrade automation  Pre 1 11   This is our recommended upgrade procedure if   one   of the following applies     Running Vault version earlier than 1 11   Opt out the  Autopilot automated upgrade   vault docs concepts integrated storage autopilot automated upgrade  features with Vault 1 11 or later   Running Vault with external storage backend such as Consul  You should consider how to apply the steps described in this document to your particular setup since HA setups can differ on whether a load balancer is in use  what addresses clients are being given to connect to Vault  standby   leader  leader only  or discovered via service discovery   etc   If you are running on Vault 1 11  with Integrated Storage and wish to enable the Autopilot upgrade automation features  read to the  automated upgrades   vault docs concepts integrated storage autopilot automated upgrades  documentation for details and the  Automate Upgrades with Vault Enterprise   vault tutorials raft raft upgrade automation  tutorial for additional guidance       HA installations  Regardless of the method you use  do not fail over from a newer version of Vault to an older version  Our suggested procedure is designed to prevent this   Please note that Vault does not support true zero downtime upgrades  but with proper upgrade procedure the downtime should be very short  a few hundred milliseconds to a second depending on how the speed of access to the storage backend     Warning title  Important    If you are currently running on Vault 1 11  with Integrated Storage and have chosen to opt out the Autopilot automated upgrade features  please disable the default automated upgrade migrations feature of the Vault  To disable this feature  follow the  Automate Upgrades with Vault Enterprise Autopilot configuration   vault tutorials raft raft upgrade automation autopilot configuration  tutorial for more details  Without disabling this feature  you may run into Lost Quorum issue as described in the  Quorum lost while upgrading the vault from 1 11 0 to later version of it  https   support hashicorp com hc en us articles 7122445204755 Quorum lost while upgrading the vault from 1 11 0 to later version of it  article     Warning   Perform these steps on each standby   1  Properly shut down Vault on the standby node via  SIGINT  or  SIGTERM  2  Replace the Vault binary with the new version  ensure that  mlock       capability is added to the new binary with     setcap   vault docs configuration disable mlock  3  Start the standby node 4  Unseal the standby node 5  Verify  vault status  shows correct Version and HA Mode is  standby  6  Review the node s logs to ensure successful startup and unseal  At this point all standby nodes are upgraded and ready to take over  The upgrade will not complete until one of the upgraded standby nodes takes over active duty   To complete the cluster upgrade   1  Properly shut down the remaining  active  node via  SIGINT  or  SIGTERM       Warning title  Important       DO NOT attempt to issue a  step down   vault docs commands operator step down      operation at any time during the upgrade process         Warning       Note      It is important that you shut the node down properly     This will release the current leadership and the HA lock  allowing a standby    node to take over with a very short delay     If you kill Vault without letting it release the lock  a standby node will    not be able to take over until the lock s timeout period has expired  This    is backend specific but could be ten seconds or more        Note   2  Replace the Vault binary with the new version  ensure that  mlock       capability is added to the new binary with     setcap   vault docs configuration disable mlock  3  Start the node 4  Unseal the node 5  Verify  vault status  shows correct Version and HA Mode is  standby  6  Review the node s logs to ensure successful startup and unseal  Internal upgrade tasks will happen after one of the upgraded standby nodes takes over active duty   Be sure to also read and follow any instructions in the version specific upgrade notes      Enterprise replication installations  See the main  upgrading   vault docs upgrading enterprise replication installations  page


vault This page contains the list of deprecations and important or breaking changes for Vault 1 9 x Please read it carefully layout docs page title Upgrading to Vault 1 9 x Guides Overview

Answer:
---
layout: docs
page_title: Upgrading to Vault 1.9.x - Guides
description: |-
  This page contains the list of deprecations and important or breaking changes
  for Vault 1.9.x. Please read it carefully.
---

# Overview

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

## OIDC provider

Vault 1.9.0 introduced the ability for Vault to be an OpenID Connect (OIDC) identity
provider. To support the feature, Vault's [default policy](/vault/docs/concepts/policies#default-policy)
was modified to include an ACL rule for its Authorization Endpoint. Due to the handling
of Vault's default policy during upgrades, existing deployments of Vault that are upgraded
to 1.9.0 will not have this required ACL rule.

If you're upgrading to 1.9.0 and want to use the new OIDC provider feature, the following
ACL rule must be added to the default policy **or** a policy associated with the Vault
[Auth Method](/vault/docs/auth) used to authenticate end-users during
the OIDC flow.

```hcl
# Allow a token to make requests to the authorization endpoint for OIDC providers.
path "identity/oidc/provider/+/authorize" {
  capabilities = ["read", "update"]
}
```

## Identity tokens

The Identity secrets engine has changed the procedure for creating Identity
token roles. When creating a role, the key parameter is required and the key
must exist. Previously, it was possible to create a role and assign it a named
key that did not yet exist despite the documentation stating otherwise.

All calls to [create or update a role](/vault/api-docs/secret/identity/tokens#create-or-update-a-role)
must be checked to ensure that roles are not being created or updated with
non-existent keys.

## SSH role parameter `allowed_extensions` behavior change

Prior versions of Vault allowed clients to specify any extension when requesting
SSH certificate [signing requests](/vault/api-docs/secret/ssh#sign-ssh-key)
if their role had an `allowed_extensions` set to `""` or was missing.

Now, Vault will reject a client request that specifies extensions if the role
parameter `allowed_extensions` is empty or missing from the role they are
associated with.

To re-enable the old behavior, update the roles with a value
of `"*"` to the `allowed_extensions` parameter allowing any/all extensions to be
specified by clients.

@include 'entity-alias-mapping.mdx'

## Deprecations

### HTTP request counter deprecation

In Vault 1.9, the internal HTTP Request count
[API](/vault/api-docs/v1.8.x/system/internal-counters#http-requests)
will be removed from the product. Calls to the endpoint will result in a 404
error with a message stating that `functionality on this path has been removed`.

Vault does not make backwards compatible guarantees on internal APIs (those
prefaced with `sys/internal`). They are subject to change and may disappear
without notice.

### Etcd v2

Support for Etcd v2 will be removed from Vault in Vault 1.10 (not this Vault
release, but the next one). The Etcd v2 API
was deprecated with the release of [Etcd
v3.5](https://etcd.io/blog/2021/announcing-etcd-3.5/), and will be
decommissioned in the Etcd v3.6 release.

Users upgrading to Vault 1.9 and planning to eventually upgrade to Vault 1.10
should prepare to [migrate](/vault/docs/commands/operator/migrate) Vault storage to
an Etcd v3 cluster prior to upgrading to Vault 1.10. All storage migrations
should have [backups](/vault/docs/concepts/storage#backing-up-vault-s-persisted-data)
taken prior to migration.

## TLS cipher suites changes

In Vault 1.9, due to changes in Go 1.17, the `tls_prefer_server_cipher_suites`
TCP configuration parameter has been deprecated and its value will be ignored.

Additionally, Go has begun doing automated cipher suite ordering and no longer
respects the order of suites given in `tls_cipher_suites`.

See [this blog post](https://go.dev/blog/tls-cipher-suites) for more information.

@include 'pki-forwarding-bug.mdx'

## Known issues

@include 'raft-panic-old-tls-key.mdx'

### Identity token backend key rotations

Existing Vault installations that use the [Identity Token
backend](/vault/api-docs/secret/identity/tokens) and have [named
keys](/vault/api-docs/secret/identity/tokens#create-a-named-key) generated will
encounter a panic when any of those existing keys pass their
`rotation_period`. This issue affects Vault 1.9.0, and is fixed in Vault 1.9.1.
Users should upgrade directly to 1.9.1 or above in order to avoid this panic.

If a panic is encountered after an upgrade to Vault 1.9.0, the named key will be
corrupted on storage and become unusable. In this case, the key will need to be
deleted and re-created. A fix to fully mitigate this panic will be addressed on
Vault 1.9.3.

### Activity log Non-Entity tokens

When upgrading Vault from 1.8 (or earlier) to 1.9 (or later), client counts of [non-entity tokens](/vault/docs/concepts/client-count#non-entity-tokens) will only include the tokens used after the upgrade.

Starting in Vault 1.9, the activity log records and de-duplicates non-entity tokens by using the namespace and token's policies to generate a unique identifier. Because Vault did not create identifiers for these tokens before 1.9, the activity log cannot know whether this token has been seen pre-1.9. To prevent inaccurate and inflated counts, the activity log will ignore any counts of non-entity tokens that were created before the upgrade and only the non-entity tokens from versions 1.9 and later will be counted.

Before upgrading, you should [query Vault usage metrics](/vault/tutorials/monitoring/usage-metrics#querying-usage-metrics) and report the usage data for billing purposes.

See the client count [overview](/vault/docs/concepts/client-count) and [FAQ](/vault/docs/concepts/client-count/faq) for more information.

layout  docs page title  Upgrading to Vault 1 9 x   Guides description       This page contains the list of deprecations and important or breaking changes   for Vault 1 9 x  Please read it carefully         Overview  This page contains the list of deprecations and important or breaking changes for Vault 1 9 x compared to 1 8  Please read it carefully      OIDC provider  Vault 1 9 0 introduced the ability for Vault to be an OpenID Connect  OIDC  identity provider  To support the feature  Vault s  default policy   vault docs concepts policies default policy  was modified to include an ACL rule for its Authorization Endpoint  Due to the handling of Vault s default policy during upgrades  existing deployments of Vault that are upgraded to 1 9 0 will not have this required ACL rule   If you re upgrading to 1 9 0 and want to use the new OIDC provider feature  the following ACL rule must be added to the default policy   or   a policy associated with the Vault  Auth Method   vault docs auth  used to authenticate end users during the OIDC flow      hcl   Allow a token to make requests to the authorization endpoint for OIDC providers  path  identity oidc provider   authorize      capabilities     read    update             Identity tokens  The Identity secrets engine has changed the procedure for creating Identity token roles  When creating a role  the key parameter is required and the key must exist  Previously  it was possible to create a role and assign it a named key that did not yet exist despite the documentation stating otherwise   All calls to  create or update a role   vault api docs secret identity tokens create or update a role  must be checked to ensure that roles are not being created or updated with non existent keys      SSH role parameter  allowed extensions  behavior change  Prior versions of Vault allowed clients to specify any extension when requesting SSH certificate  signing requests   vault api docs secret ssh sign ssh key  if their role had an  allowed extensions  set to      or was missing   Now  Vault will reject a client request that specifies extensions if the role parameter  allowed extensions  is empty or missing from the role they are associated with   To re enable the old behavior  update the roles with a value of       to the  allowed extensions  parameter allowing any all extensions to be specified by clients    include  entity alias mapping mdx      Deprecations      HTTP request counter deprecation  In Vault 1 9  the internal HTTP Request count  API   vault api docs v1 8 x system internal counters http requests  will be removed from the product  Calls to the endpoint will result in a 404 error with a message stating that  functionality on this path has been removed    Vault does not make backwards compatible guarantees on internal APIs  those prefaced with  sys internal    They are subject to change and may disappear without notice       Etcd v2  Support for Etcd v2 will be removed from Vault in Vault 1 10  not this Vault release  but the next one   The Etcd v2 API was deprecated with the release of  Etcd v3 5  https   etcd io blog 2021 announcing etcd 3 5    and will be decommissioned in the Etcd v3 6 release   Users upgrading to Vault 1 9 and planning to eventually upgrade to Vault 1 10 should prepare to  migrate   vault docs commands operator migrate  Vault storage to an Etcd v3 cluster prior to upgrading to Vault 1 10  All storage migrations should have  backups   vault docs concepts storage backing up vault s persisted data  taken prior to migration      TLS cipher suites changes  In Vault 1 9  due to changes in Go 1 17  the  tls prefer server cipher suites  TCP configuration parameter has been deprecated and its value will be ignored   Additionally  Go has begun doing automated cipher suite ordering and no longer respects the order of suites given in  tls cipher suites    See  this blog post  https   go dev blog tls cipher suites  for more information    include  pki forwarding bug mdx       Known issues   include  raft panic old tls key mdx       Identity token backend key rotations  Existing Vault installations that use the  Identity Token backend   vault api docs secret identity tokens  and have  named keys   vault api docs secret identity tokens create a named key  generated will encounter a panic when any of those existing keys pass their  rotation period   This issue affects Vault 1 9 0  and is fixed in Vault 1 9 1  Users should upgrade directly to 1 9 1 or above in order to avoid this panic   If a panic is encountered after an upgrade to Vault 1 9 0  the named key will be corrupted on storage and become unusable  In this case  the key will need to be deleted and re created  A fix to fully mitigate this panic will be addressed on Vault 1 9 3       Activity log Non Entity tokens  When upgrading Vault from 1 8  or earlier  to 1 9  or later   client counts of  non entity tokens   vault docs concepts client count non entity tokens  will only include the tokens used after the upgrade   Starting in Vault 1 9  the activity log records and de duplicates non entity tokens by using the namespace and token s policies to generate a unique identifier  Because Vault did not create identifiers for these tokens before 1 9  the activity log cannot know whether this token has been seen pre 1 9  To prevent inaccurate and inflated counts  the activity log will ignore any counts of non entity tokens that were created before the upgrade and only the non entity tokens from versions 1 9 and later will be counted   Before upgrading  you should  query Vault usage metrics   vault tutorials monitoring usage metrics querying usage metrics  and report the usage data for billing purposes   See the client count  overview   vault docs concepts client count  and  FAQ   vault docs concepts client count faq  for more information