vault page title Configure Vault ServiceNow Credential Resolver MID server properties Configuring the Vault credential resolver layout docs This section documents the configurables for the Vault ServiceNow Credential Resolver

Answer:
---
layout: docs
page_title: Configure Vault ServiceNow Credential Resolver
description: This section documents the configurables for the Vault ServiceNow Credential Resolver.
---

# Configuring the Vault credential resolver

## MID server properties

The following [properties] are supported by the Vault Credential Resolver:

- `mid.external_credentials.vault.address` `(string: "")` - Address of Vault Agent as resolveable by the MID server.
  For example, if Vault Agent is on the same server as the MID server it could be `https://127.0.0.1:8200`.

- `mid.external_credentials.vault.ca` `(string: "")` - The CA certificate to trust for TLS in PEM format. If unset,
  the system's trusted CAs will be used.

- `mid.external_credentials.vault.tls_skip_verify` `(string: "")` - When set to true, skips verification of the Vault server
  TLS certificiate. Setting this to true is not recommended for production.

[properties]: https://docs.servicenow.com/bundle/quebec-servicenow-platform/page/product/mid-server/reference/r_MIDServerProperties.html#t_SetMIDServerProperties

## Configuring discovery credentials

To consume Vault credentials from your MID server, you will need to:

* Create a secret in Vault
* Configure the resolver to use that secret

### Creating a secret in Vault

The credential resolver supports reading credentials from the following secret engines:

* [Active Directory](/vault/docs/secrets/ad)
* [AD/OpenLDAP](/vault/docs/secrets/ldap)
* [AWS](/vault/docs/secrets/aws)
* [KV v1](/vault/docs/secrets/kv/kv-v1)
* [KV v2](/vault/docs/secrets/kv/kv-v2)

When creating KV secrets, you must use the following keys for each component
to ensure it is correctly mapped to ServiceNow's credential fields:

Key         | Description                            | Supported aliases
------------|----------------------------------------|------------------
username    | The username                           | access_key
password    | The password                           | secret_key, current_password
private_key | The private SSH key                    |
passphrase  | The passphrase for the private SSH key |

Most ServiceNow credential types will expect at least a username and either
a password or a private key. To help surface errors early, the credential
resolver validates that a username and password are present for:

* aws
* basic
* jdbc
* jms
* ssh_password
* vmware
* windows

The credential resolver expects the following types to specify at least
a username and a private key:

* api_key
* cfg_chef_credentials
* infoblox
* sn_cfg_ansible
* sn_disco_certmgmt_certificate_ca
* ssh_private_key

For SNMPv3 credentials, the credential resolver can accept up to five values:

* username
* auth-protocol
* auth-key
* privacy-protocol
* privacy-key

Depending on the configuration of the SNMP endpoint, the username at least will always be required. See below for different SNMP endpoint configurations:

Level         | Authentication | Encryption | What Happens
--------------|----------------|------------|------------------------
noAuthNoPriv  | Username       | None       | Username match for auth
authNoPriv    | MD5 or SHA     | None       | Auth based on HMAC-MD5 or HMAC-SHA algorithms
authPriv      | MD5 or SHA     | DES        | Auth based on HMAC-MD5 or HMAC-SHA algorithms; provides DES 56-bit encryption based on (CBC)-DES (DES-56)

### Configuring the resolver to use a secret

<ImageConfig hideBorder caption="Vault credential resolver">

![Partial screenshot of the ServiceNow UI showing the search dialog for adding a Vault configuration by name](/img/service-now/vault-credential-resolver-fqcn.png)

</ImageConfig>

In the ServiceNow UI:

1. Navigate to "Discovery - Credentials → New".
1. Choose a type from the list.
1. Select "External credential store".
1. Provide a fully qualified collection name (FQCN):
    - **Xanadu (Q4-2024) or newer**:  use `com.snc.discovery.CredentialResolver`
    - **Versions prior to Xanadu (Q4-2024)**: leave blank or use "None"
1. Provide a meaningful name for the resolver.
1. Set "Credential ID" to the
   [ReadSecretVersion endpoint](/vault/api-docs/secret/kv/kv-v2#read-secret-version)
   of your secrets plugin and credential. For example, the endpoint
   for a secret stored on the path `ssh` under a KV v2 secret engine mounted at
   `secret` is `/secret/data/ssh`.
1. Click "Test credential" then select a MID server and target to test your
   configuration.

layout  docs page title  Configure Vault ServiceNow Credential Resolver description  This section documents the configurables for the Vault ServiceNow Credential Resolver         Configuring the Vault credential resolver     MID server properties  The following  properties  are supported by the Vault Credential Resolver      mid external credentials vault address    string         Address of Vault Agent as resolveable by the MID server    For example  if Vault Agent is on the same server as the MID server it could be  https   127 0 0 1 8200       mid external credentials vault ca    string         The CA certificate to trust for TLS in PEM format  If unset    the system s trusted CAs will be used      mid external credentials vault tls skip verify    string         When set to true  skips verification of the Vault server   TLS certificiate  Setting this to true is not recommended for production    properties   https   docs servicenow com bundle quebec servicenow platform page product mid server reference r MIDServerProperties html t SetMIDServerProperties     Configuring discovery credentials  To consume Vault credentials from your MID server  you will need to     Create a secret in Vault   Configure the resolver to use that secret      Creating a secret in Vault  The credential resolver supports reading credentials from the following secret engines      Active Directory   vault docs secrets ad     AD OpenLDAP   vault docs secrets ldap     AWS   vault docs secrets aws     KV v1   vault docs secrets kv kv v1     KV v2   vault docs secrets kv kv v2   When creating KV secrets  you must use the following keys for each component to ensure it is correctly mapped to ServiceNow s credential fields   Key           Description                              Supported aliases                                                                          username      The username                             access key password      The password                             secret key  current password private key   The private SSH key                      passphrase    The passphrase for the private SSH key    Most ServiceNow credential types will expect at least a username and either a password or a private key  To help surface errors early  the credential resolver validates that a username and password are present for     aws   basic   jdbc   jms   ssh password   vmware   windows  The credential resolver expects the following types to specify at least a username and a private key     api key   cfg chef credentials   infoblox   sn cfg ansible   sn disco certmgmt certificate ca   ssh private key  For SNMPv3 credentials  the credential resolver can accept up to five values     username   auth protocol   auth key   privacy protocol   privacy key  Depending on the configuration of the SNMP endpoint  the username at least will always be required  See below for different SNMP endpoint configurations   Level           Authentication   Encryption   What Happens                                                                       noAuthNoPriv    Username         None         Username match for auth authNoPriv      MD5 or SHA       None         Auth based on HMAC MD5 or HMAC SHA algorithms authPriv        MD5 or SHA       DES          Auth based on HMAC MD5 or HMAC SHA algorithms  provides DES 56 bit encryption based on  CBC  DES  DES 56        Configuring the resolver to use a secret   ImageConfig hideBorder caption  Vault credential resolver      Partial screenshot of the ServiceNow UI showing the search dialog for adding a Vault configuration by name   img service now vault credential resolver fqcn png     ImageConfig   In the ServiceNow UI   1  Navigate to  Discovery   Credentials  rarr  New   1  Choose a type from the list  1  Select  External credential store   1  Provide a fully qualified collection name  FQCN           Xanadu  Q4 2024  or newer     use  com snc discovery CredentialResolver          Versions prior to Xanadu  Q4 2024     leave blank or use  None  1  Provide a meaningful name for the resolver  1  Set  Credential ID  to the     ReadSecretVersion endpoint   vault api docs secret kv kv v2 read secret version     of your secrets plugin and credential  For example  the endpoint    for a secret stored on the path  ssh  under a KV v2 secret engine mounted at     secret  is   secret data ssh   1  Click  Test credential  then select a MID server and target to test your    configuration


vault Installation steps for the Vault ServiceNow Credential Resolver page title Install Vault ServiceNow Credential Resolver Installing the Vault credential resolver layout docs Prerequisites

Answer:
---
layout: docs
page_title: Install Vault ServiceNow Credential Resolver
description: Installation steps for the Vault ServiceNow Credential Resolver.
---

# Installing the Vault credential resolver

## Prerequisites

* ServiceNow version Quebec+ (untested on previous versions)
* MID server version Quebec+ (untested on previous versions)
* Discovery and external credential plugins activated on ServiceNow
* Working Vault deployment accessible from the MID server

## Installing Vault agent

* Select your desired auth method from Agent's [supported auth methods](/vault/docs/agent-and-proxy/autoauth/methods)
  and set it up in Vault
  * For example, to set up AppRole auth and a role called `role1` with the `demo` policy attached:

    ```bash
    vault auth enable approle
    vault policy write demo - <<EOF
    path "secret/*" {
      capabilities = ["read"]
    }
    EOF
    vault write auth/approle/role/role1 bind_secret_id=true token_policies=demo
    ```

  * To get the files required for the example Agent config below, you can then
    run:

    ```bash
    echo -n $(vault read -format json auth/approle/role/role1/role-id | jq -r '.data.role_id') > /path/to/roleID
    echo -n $(vault write -format json -f auth/approle/role/role1/secret-id | jq -r '.data.secret_id') > /path/to/secretID
    ```

* Create an `agent.hcl` config file. Your exact configuration may vary, but you
  must set `cache.use_auto_auth_token = true`, and the `listener`, `vault` and
  `auto_auth` blocks are also required to set up a working Agent, e.g.:

  ```hcl
  listener "tcp" {
    address = "127.0.0.1:8200"
    tls_disable = false
    tls_cert_file = "/path/to/cert.pem"
    tls_key_file = "/path/to/key.pem"
  }

  cache {
    use_auto_auth_token = true
  }

  vault {
    address = "http://vault.example.com:8200"
  }

  auto_auth {
      method {
          type = "approle"
          config = {
              role_id_file_path = "/path/to/roleID"
              secret_id_file_path = "/path/to/secretID"
              remove_secret_id_file_after_reading = false
          }
      }
  }
  ```

* Install Vault Agent as a service running `vault agent -config=/path/to/agent.hcl`
  * Documentation for Windows service installation [here](/vault/docs/agent-and-proxy/agent/winsvc)

## Uploading JAR file to MID server

<Warning heading="Use the ServiceNow app store to install Vault Credential Resolver">
  The steps documented below are for **pre ServiceNow UTAH versions**.

  As of ServiceNow version UTAH, use the "HashiCorp Vault Credential Resolver" App
  from the ServiceNow App store to install the Vault Credential Resolver and verify
  the jar file installed is `vault-servicenow-credential-resolver`. If you wish to
  use a custom name, you must manually rename the deployed jar.
</Warning>

* Download the latest version of the Vault Credential Resolver JAR file from
  [releases.hashicorp.com](https://releases.hashicorp.com/vault-servicenow-credential-resolver/)
* In ServiceNow, navigate to "MID server - JAR files" -> New
  * Manage Attachments -> upload Vault Credential Resolver JAR
  * Fill in name, version etc as desired
  * Click Submit
* Navigate to "MID server - Properties" -> New
  * Set Name: `mid.external_credentials.vault.address`, Value: Address of Vault
    Agent listener from previous step, e.g. `http://127.0.0.1:8200`
  * **Optional:** Set the property `mid.external_credentials.vault.ca` to the
    trusted CA in PEM format if using TLS between the MID server and Vault
    Agent with a self-signed certificate.

## Next steps

See [configuration](/vault/docs/platform/servicenow/configuration) for details on
configuring the resolver and using credentials for discovery.

layout  docs page title  Install Vault ServiceNow Credential Resolver description  Installation steps for the Vault ServiceNow Credential Resolver         Installing the Vault credential resolver     Prerequisites    ServiceNow version Quebec   untested on previous versions    MID server version Quebec   untested on previous versions    Discovery and external credential plugins activated on ServiceNow   Working Vault deployment accessible from the MID server     Installing Vault agent    Select your desired auth method from Agent s  supported auth methods   vault docs agent and proxy autoauth methods    and set it up in Vault     For example  to set up AppRole auth and a role called  role1  with the  demo  policy attached          bash     vault auth enable approle     vault policy write demo     EOF     path  secret            capabilities     read             EOF     vault write auth approle role role1 bind secret id true token policies demo              To get the files required for the example Agent config below  you can then     run          bash     echo  n   vault read  format json auth approle role role1 role id   jq  r   data role id      path to roleID     echo  n   vault write  format json  f auth approle role role1 secret id   jq  r   data secret id      path to secretID            Create an  agent hcl  config file  Your exact configuration may vary  but you   must set  cache use auto auth token   true   and the  listener    vault  and    auto auth  blocks are also required to set up a working Agent  e g         hcl   listener  tcp        address    127 0 0 1 8200      tls disable   false     tls cert file     path to cert pem      tls key file     path to key pem         cache       use auto auth token   true        vault       address    http   vault example com 8200         auto auth         method             type    approle            config                   role id file path     path to roleID                secret id file path     path to secretID                remove secret id file after reading   false                                  Install Vault Agent as a service running  vault agent  config  path to agent hcl      Documentation for Windows service installation  here   vault docs agent and proxy agent winsvc      Uploading JAR file to MID server   Warning heading  Use the ServiceNow app store to install Vault Credential Resolver     The steps documented below are for   pre ServiceNow UTAH versions       As of ServiceNow version UTAH  use the  HashiCorp Vault Credential Resolver  App    from the ServiceNow App store to install the Vault Credential Resolver and verify   the jar file installed is  vault servicenow credential resolver   If you wish to   use a custom name  you must manually rename the deployed jar     Warning     Download the latest version of the Vault Credential Resolver JAR file from    releases hashicorp com  https   releases hashicorp com vault servicenow credential resolver     In ServiceNow  navigate to  MID server   JAR files     New     Manage Attachments    upload Vault Credential Resolver JAR     Fill in name  version etc as desired     Click Submit   Navigate to  MID server   Properties     New     Set Name   mid external credentials vault address   Value  Address of Vault     Agent listener from previous step  e g   http   127 0 0 1 8200        Optional    Set the property  mid external credentials vault ca  to the     trusted CA in PEM format if using TLS between the MID server and Vault     Agent with a self signed certificate      Next steps  See  configuration   vault docs platform servicenow configuration  for details on configuring the resolver and using credentials for discovery


vault This guide assumes you are installing the Vault EKM Provider for the first time page title Install the Vault EKM Provider layout docs For upgrade instructions see upgrading vault docs platform mssql upgrading Installation steps for the Vault EKM Provider for Microsoft SQL Server Installing the Vault EKM provider

Answer:
---
layout: docs
page_title: Install the Vault EKM Provider
description: Installation steps for the Vault EKM Provider for Microsoft SQL Server.
---

# Installing the Vault EKM provider

This guide assumes you are installing the Vault EKM Provider for the first time.
For upgrade instructions, see [upgrading](/vault/docs/platform/mssql/upgrading).

## Prerequisites

* Vault Enterprise server 1.9+ with a license for the Advanced Data Protection Key Management module
* Microsoft Windows Server operating system
* Microsoft SQL Server 2012 or newer for Windows (Windows SQL Server Express and SQL Server for Linux [does not support EKM][linux-ekm])
* An authenticated Vault client

To check your Vault version and license, you can run:

```bash
vault status
vault license get -format=json
```

The list of features should include "Key Management Transparent Data Encryption".

[linux-ekm]: https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-editions-and-components-2019?view=sql-server-ver15#Unsupported

## Installing the Vault EKM provider

## Configuring Vault

The EKM provider requires AppRole auth and the Transit secret engine to be setup
on the Vault server. The steps below can be used to configure Vault ready for the
EKM provider to use it.

-> **Note:** rsa-2048 is currently the only supported key type.

1. Set up AppRole auth:

    ```bash
    vault auth enable approle
    vault write auth/approle/role/ekm-encryption-key-role \
        token_ttl=20m \
        max_token_ttl=30m \
        token_policies=tde-policy
    ```

-> **Note:** After authenticating to Vault with the AppRole, the EKM provider
will re-use the token it receives until it expires, at which point it will
authenticate using the AppRole credentials again; it will not attempt to renew
its token. The example AppRole configuraiton here will work for this, but keep
that in mind if you choose to use a different AppRole configuration.

1. Retrieve the AppRole ID and secret ID for use later when configuring SQL Server:

    ```bash
    vault read auth/approle/role/ekm-encryption-key-role/role-id
    vault write -f auth/approle/role/ekm-encryption-key-role/secret-id
    ```

1. Enable the transit secret engine and create a key:

    ```bash
    vault secrets enable transit
    vault write -f transit/keys/ekm-encryption-key type="rsa-2048"
    ```

1. Create a policy for the Vault EKM provider to use. The following policy has
    the minimum required permissions:

    ```bash
    vault policy write tde-policy -<<EOF
    path "transit/keys/ekm-encryption-key" {
        capabilities = ["create", "read", "update", "delete"]
    }

    path "transit/keys" {
        capabilities = ["list"]
    }

    path "transit/encrypt/ekm-encryption-key" {
        capabilities = ["update"]
    }

    path "transit/decrypt/ekm-encryption-key" {
        capabilities = ["update"]
    }

    path "sys/license/status" {
        capabilities = ["read"]
    }
    EOF
    ```

## Configuring SQL server

The remaining steps are all run on the database server.

### Install the EKM provider on the server

1. Download and run the latest Vault EKM provider installer from
  [releases.hashicorp.com](https://releases.hashicorp.com/vault-mssql-ekm-provider/)
1. Enter your Vault server's address when prompted and complete the installer
1. If you need to configure non-default namespace or mount paths for your AppRole and
   Transit engines, see [configuration](/vault/docs/platform/mssql/configuration).

### Configure the EKM provider using SQL

Open Microsoft SQL Server Management Studio, and run the queries below to complete
installation.

1. Enable the EKM feature and create a cryptographic provider using the folder
   you just installed the EKM provider into.

    ```sql
    -- Enable advanced options
    USE master;
    GO

    EXEC sp_configure 'show advanced options', 1;
    GO

    RECONFIGURE;
    GO

    -- Enable EKM provider
    EXEC sp_configure 'EKM provider enabled', 1;
    GO

    RECONFIGURE;
    GO

    CREATE CRYPTOGRAPHIC PROVIDER TransitVaultProvider
    FROM FILE = 'C:\Program Files\HashiCorp\Transit Vault EKM Provider\TransitVaultEKM.dll'
    GO
    ```

1. Next, create credentials for an admin to use EKM with your AppRole role and
    secret ID from above:

    ```sql
    -- Replace <approle-role-id> and <approle-secret-id> with the values from
    -- the earlier vault commands:
    -- vault read auth/approle/role/ekm-encryption-key/role-id
    -- vault write -f auth/approle/role/ekm-encryption-key/secret-id
    CREATE CREDENTIAL TransitVaultCredentials
        WITH IDENTITY = '<approle-role-id>',
        SECRET = '<approle-secret-id>'
    FOR CRYPTOGRAPHIC PROVIDER TransitVaultProvider;
    GO

    -- Replace <domain>\<login> with the SQL Server administrator's login
    ALTER LOGIN "<domain>\<login>" ADD CREDENTIAL TransitVaultCredentials;
    ```

1. You can now create an asymmetric key using the transit key set up earlier:

    ```sql
    CREATE ASYMMETRIC KEY TransitVaultAsymmetric
    FROM PROVIDER TransitVaultProvider
    WITH
    CREATION_DISPOSITION = OPEN_EXISTING,
    PROVIDER_KEY_NAME = 'ekm-encryption-key';
    ```

    -> **Note:** This is the first step at which the EKM provider will communicate with Vault. If
    Vault is misconfigured, this step is likely to fail. See
    [troubleshooting](/vault/docs/platform/mssql/troubleshooting) for tips on specific error codes.

1. Create another login from the new asymmetric key:

    ```sql
     -- Replace <approle-role-id> and <approle-secret-id> with the values from
    -- the earlier vault commands again
    CREATE CREDENTIAL TransitVaultTDECredentials
        WITH IDENTITY = '<approle-role-id>',
        SECRET = '<approle-secret-id>'
    FOR CRYPTOGRAPHIC PROVIDER TransitVaultProvider;
    GO

    CREATE LOGIN TransitVaultTDELogin
    FROM ASYMMETRIC KEY TransitVaultAsymmetric;
    GO

    ALTER LOGIN TransitVaultTDELogin
    ADD CREDENTIAL TransitVaultTDECredentials;
    GO
    ```

1. Finally, you can enable TDE and protect the database encryption key with
   the asymmetric key managed by Vault's Transit secret engine:

    ```sql
    CREATE DATABASE TestTDE
    GO

    USE TestTDE;
    GO

    CREATE DATABASE ENCRYPTION KEY
    WITH ALGORITHM = AES_256
    ENCRYPTION BY SERVER ASYMMETRIC KEY TransitVaultAsymmetric;
    GO

    ALTER DATABASE TestTDE
    SET ENCRYPTION ON;
    GO
    ```

1. Check the status of database encryption using the following queries:
    ```sql
    SELECT * FROM sys.dm_database_encryption_keys;

    SELECT (SELECT name FROM sys.databases WHERE database_id = k.database_id) as name,
        encryption_state, key_algorithm, key_length,
        encryptor_type, encryption_state_desc, encryption_scan_state_desc FROM sys.dm_database_encryption_keys k;

    ```

## Key rotation

See [key rotation](/vault/docs/platform/mssql/rotation) for guidance on rotating
the encryption keys.

layout  docs page title  Install the Vault EKM Provider description  Installation steps for the Vault EKM Provider for Microsoft SQL Server         Installing the Vault EKM provider  This guide assumes you are installing the Vault EKM Provider for the first time  For upgrade instructions  see  upgrading   vault docs platform mssql upgrading       Prerequisites    Vault Enterprise server 1 9  with a license for the Advanced Data Protection Key Management module   Microsoft Windows Server operating system   Microsoft SQL Server 2012 or newer for Windows  Windows SQL Server Express and SQL Server for Linux  does not support EKM  linux ekm     An authenticated Vault client  To check your Vault version and license  you can run      bash vault status vault license get  format json      The list of features should include  Key Management Transparent Data Encryption     linux ekm   https   docs microsoft com en us sql linux sql server linux editions and components 2019 view sql server ver15 Unsupported     Installing the Vault EKM provider     Configuring Vault  The EKM provider requires AppRole auth and the Transit secret engine to be setup on the Vault server  The steps below can be used to configure Vault ready for the EKM provider to use it        Note    rsa 2048 is currently the only supported key type   1  Set up AppRole auth          bash     vault auth enable approle     vault write auth approle role ekm encryption key role           token ttl 20m           max token ttl 30m           token policies tde policy               Note    After authenticating to Vault with the AppRole  the EKM provider will re use the token it receives until it expires  at which point it will authenticate using the AppRole credentials again  it will not attempt to renew its token  The example AppRole configuraiton here will work for this  but keep that in mind if you choose to use a different AppRole configuration   1  Retrieve the AppRole ID and secret ID for use later when configuring SQL Server          bash     vault read auth approle role ekm encryption key role role id     vault write  f auth approle role ekm encryption key role secret id          1  Enable the transit secret engine and create a key          bash     vault secrets enable transit     vault write  f transit keys ekm encryption key type  rsa 2048           1  Create a policy for the Vault EKM provider to use  The following policy has     the minimum required permissions          bash     vault policy write tde policy    EOF     path  transit keys ekm encryption key            capabilities     create    read    update    delete              path  transit keys            capabilities     list              path  transit encrypt ekm encryption key            capabilities     update              path  transit decrypt ekm encryption key            capabilities     update              path  sys license status            capabilities     read             EOF             Configuring SQL server  The remaining steps are all run on the database server       Install the EKM provider on the server  1  Download and run the latest Vault EKM provider installer from    releases hashicorp com  https   releases hashicorp com vault mssql ekm provider   1  Enter your Vault server s address when prompted and complete the installer 1  If you need to configure non default namespace or mount paths for your AppRole and    Transit engines  see  configuration   vault docs platform mssql configuration        Configure the EKM provider using SQL  Open Microsoft SQL Server Management Studio  and run the queries below to complete installation   1  Enable the EKM feature and create a cryptographic provider using the folder    you just installed the EKM provider into          sql        Enable advanced options     USE master      GO      EXEC sp configure  show advanced options   1      GO      RECONFIGURE      GO         Enable EKM provider     EXEC sp configure  EKM provider enabled   1      GO      RECONFIGURE      GO      CREATE CRYPTOGRAPHIC PROVIDER TransitVaultProvider     FROM FILE    C  Program Files HashiCorp Transit Vault EKM Provider TransitVaultEKM dll      GO          1  Next  create credentials for an admin to use EKM with your AppRole role and     secret ID from above          sql        Replace  approle role id  and  approle secret id  with the values from        the earlier vault commands         vault read auth approle role ekm encryption key role id        vault write  f auth approle role ekm encryption key secret id     CREATE CREDENTIAL TransitVaultCredentials         WITH IDENTITY     approle role id            SECRET     approle secret id       FOR CRYPTOGRAPHIC PROVIDER TransitVaultProvider      GO         Replace  domain   login  with the SQL Server administrator s login     ALTER LOGIN   domain   login   ADD CREDENTIAL TransitVaultCredentials           1  You can now create an asymmetric key using the transit key set up earlier          sql     CREATE ASYMMETRIC KEY TransitVaultAsymmetric     FROM PROVIDER TransitVaultProvider     WITH     CREATION DISPOSITION   OPEN EXISTING      PROVIDER KEY NAME    ekm encryption key                     Note    This is the first step at which the EKM provider will communicate with Vault  If     Vault is misconfigured  this step is likely to fail  See      troubleshooting   vault docs platform mssql troubleshooting  for tips on specific error codes   1  Create another login from the new asymmetric key          sql         Replace  approle role id  and  approle secret id  with the values from        the earlier vault commands again     CREATE CREDENTIAL TransitVaultTDECredentials         WITH IDENTITY     approle role id            SECRET     approle secret id       FOR CRYPTOGRAPHIC PROVIDER TransitVaultProvider      GO      CREATE LOGIN TransitVaultTDELogin     FROM ASYMMETRIC KEY TransitVaultAsymmetric      GO      ALTER LOGIN TransitVaultTDELogin     ADD CREDENTIAL TransitVaultTDECredentials      GO          1  Finally  you can enable TDE and protect the database encryption key with    the asymmetric key managed by Vault s Transit secret engine          sql     CREATE DATABASE TestTDE     GO      USE TestTDE      GO      CREATE DATABASE ENCRYPTION KEY     WITH ALGORITHM   AES 256     ENCRYPTION BY SERVER ASYMMETRIC KEY TransitVaultAsymmetric      GO      ALTER DATABASE TestTDE     SET ENCRYPTION ON      GO          1  Check the status of database encryption using the following queries         sql     SELECT   FROM sys dm database encryption keys       SELECT  SELECT name FROM sys databases WHERE database id   k database id  as name          encryption state  key algorithm  key length          encryptor type  encryption state desc  encryption scan state desc FROM sys dm database encryption keys k               Key rotation  See  key rotation   vault docs platform mssql rotation  for guidance on rotating the encryption keys


vault Software Release date Mar 23 2022 Vault 1 10 0 release notes layout docs This page contains release notes for Vault 1 10 0 page title 1 10 0

Answer:
---
layout: docs
page_title: 1.10.0
description: |-
  This page contains release notes for Vault 1.10.0
---

# Vault 1.10.0 release notes

**Software Release date:** Mar 23, 2022

**Summary:** Vault version 1.10.0 offers features and enhancements that improve the user experience while closing the loop on key issues previously encountered by our customers. We are providing a summary of these improvements in these release notes.

We encourage you to upgrade to the latest release to take advantage of the new benefits that we are providing. Additionally, with this latest release, we offer solutions to critical feature gaps that have been identified previously. For further information on product improvements, including a comprehensive list of bug fixes, please refer to the [Changelog](https://github.com/hashicorp/vault/blob/main/CHANGELOG.md) within the Vault 1.10.0 release.

Some of these enhancements and changes in this release include:

- Ability to view client counts per auth and changes to clients over months, therefore, providing more granular visibility into clients.
- Extended the `sys/remount` API endpoint to support moving secrets engines and auth method mounts from one location to another, within a namespace or across namespaces.
- Improved security posture that includes MFA on login for Vault Community Edition customers.
- Ability to implicitely achieve consistency via tokens.
- Support of PKCE on Vault’s OIDC auth method with Telemetry support for the Vault Agent.
- Improvement of key areas and parity to support using Terraform Provider with Vault.

## New features

This section describes the new features introduced as part of Vault

### Multi-Factor authentication (MFA) for Vault Community Edition

Vault has had support for the [Step-up Enterprise MFA](/vault/docs/enterprise/mfa) as part of its Enterprise edition. The Step-up Enterprise MFA allows having an MFA on login, or for step-up access to sensitive resources in Vault.

With Vault 1.10.0, MFA as part of [login](/vault/docs/auth/login-mfa) is now supported for Vault Community Edition. This demonstrates HashiCorp’s thought leadership in security and its continued endeavor to enable all Vault users to employ strong security policies with Vault.

~> **Note:** The Legacy MFA in Vault Community Edition is a [deprecated](/vault/docs/deprecation) feature and will be removed in Vault 1.11.

Refer to the [Login MFA FAQ](/vault/docs/auth/login-mfa/faq) to understand the various MFA workflows that are supported in Vault 1.10.0.

### Vault OIDC provider with PKCE support

Vault’s support to act as an OIDC provider is now generally available. Furthermore, Vault’s OIDC provider functionality can now support PKCE for authorization code flow as well. Thanks to all the excellent community feedback received, we have simplified the user experience around configuration of OIDC provider functionality.

### Caching support for Vault lambda extension

With 0.6.0, Vault Lambda Extension supports [caching](https://github.com/hashicorp/vault-lambda-extension#caching) in the local proxy server to avoid proxying every request to enable setting expiry time and invalidate cache, as needed.

### Terraform provider for Vault

We have introduced three new resources to enable configuration of the [KMIP secrets engine](https://registry.terraform.io/providers/hashicorp/vault/latest/docs/resources/kmip_secret_backend) using the Terraform Provider for Vault. In addition, frequent releases on the Terraform Provider for Vault have been incorporating the ability to configure newer resources and data sources. Please read the [documentation](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) for more details.

### KV secrets engine v2 patch operations

We now support an additional method for managing [KV v2 secrets](/vault/api-docs/secret/kv/kv-v2) to maintain least privilege security in certain types of automated environments. This feature creates a new PATCH capability that enables partial updates to KV v2 secrets without requiring the READ privilege to the entire endpoint for an entity.

### DB2 dynamic secrets support

Vault operators can leverage the openldap secrets engine to manage credentials for IBM DB2 and the LDAP security plugin for Db2. This allows Db2 to offload authentication and authorization to the LDAP security plugin and allows Vault to manage static credentials or even generate dynamic users. For more details, refer to the For more details, refer to the [IBM Db2 Credentials Management](/vault/tutorials/secrets-management/ibm-db2-openldap) tutorial.

### Temporal transit key rotation

Proper key management includes occasionally rotating encryption keys to reduce the risks of a nonce reuse and opportunities for keys to be compromised. Previously, there was no automated way to rotate keys that is native to Vault. Now, we have provided a new configuration element on transit keys and tokenization transform configurations where a time interval triggers the keys to automatically rotate after the interval has lapsed.

### PKI HSM forwarding

To address security and compliance needs, customers may require that keys be either created or stored within Hardware Security Models (HSMs). Vault 1.10.0 introduces an accommodation for this requirement with regards to the PKI Secrets Engine. We now support offloading selected PKI operations to HSMs, in particular allowing customers to both generate new PKI key pairs and sign/verify some certificate workflows. All of these operations are conducted in a way that never allows the private key material to leave the secure confines of the HSM itself.

### AWS and AKV KMS forwarding

The work done above to support HSM-backed PKI operations inspired us to consider what other key possession paradigms we could support. This led us to extend the implementation to support Cloud Key Management Systems in addition to HSMs. In Vault 1.10.0, users may generate new PKI pairs and perform sign/verify certificate workflows, all with those keys never leaving the cloud KMS itself. Vault 1.10.0 provides support for AWS Key Management Service and Azure Key Vault Key Management Service.

### Server side consistent tokens

Vault’s [eventual consistency](/vault/docs/enterprise/consistency) model precludes read-after-write guarantees when clients interact with performance standbys or performance replication clusters. The [Client Controlled Consistency](/vault/docs/enterprise/consistency#vault-1-7-mitigations) mitigations supported with Vault 1.7 provide ways to achieve consistency through client modifications or by using the agent for proxied requests, which is not possible in all cases. The Server Side Consistent Tokens feature provides an implicit way to achieve consistency by embedding the minimum Write-Ahead-Log state information in the Service tokens returned from logins or token-create requests. This feature introduces changes in the token format and the new tokesn will be the default tokens starting in Vault 1.10.0. Vault 1.10.0 is backwards compatible with old tokens.

See [Replication](/vault/docs/configuration/replication), [Vault Eventual Consistency](/vault/docs/enterprise/consistency), [Upgrade to 1.10.0](/vault/docs/upgrading/upgrade-to-1.10.x) and [Server Side Consistent Token FAQ](/vault/docs/faq/ssct) to understand the various consistency options available with Vault 1.10.0 and the considerations to be aware of prior to selecting an option for your use case.

## Vault agent features

### Support for telemetry

Starting with Vault 1.10.0, the Vault Agent supports a new metrics endpoint and [Telemetry](/vault/docs/agent#telemetry-stanza) metrics around run time, authentication success, authentication failures, cache hits, cache misses, proxy succes, and proxy client errors. This Vault Agent Telemetry should greatly help with the retrieval of key operational insights for Vault Agent deployments.

### User-assigned managed identities for auto auth in Azure

With this [enhancement](/vault/docs/agent/autoauth/methods/azure), users can specify user-assigned managed identities via the `object_id` and `client_id` when configuring Vault agent auto-auth for Azure. This enables users that have more than one user-assigned managed identity associated with their VM to specify which one they'd like to use when authenticating via the Vault's Azure auth method. Note that providing these parameters is an "exclusive or" operation.

### Quit API endpoint with config

Previously, for instances where the Agent is a sidecar in a Kubernetes job and the job hangs, you must either use `shareProcessNamespace: true` for the container so that the process kill signals can be sent, or avoid the sidecar container entirely and solely rely on an init container. With this [enhancement](/vault/docs/agent#quit), we have added support for a Quit API endpoint to automatically shut down the Vault Agent, therefore eliminating the need to perform the workarounds.

## Other features and enhancements

This section describes other features and enhancements introduced as part of the Vault 1.10.0 release.

### Client count improvements

We have introduced auth mount-based attribution of clients to help better understand where clients are being used within a cluster. This is available via UI and API. This is an enhancement on top of the namespace attribution capability we introduced in Vault 1.9.

We have also introduced the ability to view changes to clients month over month via the client count API, and made other UI enhancements. Refer to [What is a Client?](/vault/docs/concepts/client-count) and [Client Count FAQ](/vault/docs/concepts/client-count/faq) for more details.

### Mount migration

We have made improvements to the `sys/remount` API endpoint to simplify the complexities of moving data, such as secret engine and authentication method configuration from one mount to another, within a namespace or across namespaces. This can help with restructuring namespaces and mounts for various reasons, including migrating mounts from root to other namespaces when transitioning to using namespaces for the first time. For step-by-step instructions, refer to the [Mount Move](/vault/tutorials/enterprise/mount-move) tutorial.

### Scaling external database plugins

Database plugins can now implement [plugin multiplexing](/vault/docs/plugins/plugin-architecture#plugin-multiplexing) which allows a single plugin process to be used for multiple database connections. Database plugin multiplexing will be enabled on the Oracle Database plugin starting in v0.6.0. We will extend this functionality to additional database plugins in subsequent releases.

Any external database plugins that want to adopt multiplexing support will have to update their main.go call from [dbplugin.Serve()](https://github.com/hashicorp/vault/blob/sdk/v0.4.1/sdk/database/dbplugin/v5/plugin_server.go#L13) to [dbplugin.ServeMultiplex()](https://github.com/hashicorp/vault/blob/sdk/v0.4.1/sdk/database/dbplugin/v5/plugin_server.go#L42). Multiplexable database plugins are compatible with older versions of Vault down to Vault 1.6. Refer to this [Oracle Database PR](https://github.com/hashicorp/vault-plugin-database-oracle/pull/74) as an example of the upgrade process.

### Consul secrets engine enhancements

Consul has supported [namespace](/consul/docs/enterprise/namespaces), [admin partitions](/consul/docs/enterprise/admin-partitions) and [ACL roles](/consul/commands/acl/role) for some time now. In this release we have added enhancements to the Consul Secrets engine to support namespace awareness and add admin partition and role support for Consul ACL tokens. This significantly simplifies the integrations for customers who want to achieve a zero trust security posture with both Vault and Consul.

### Using sessionStorage instead of localStorage for the Vault UI

Prior to Vault 1.10.0, the Vault UI used localStorage to store authentication information. The data in localStorage was persisted in browsers and removed only on demand. Now, we have switched the Vault UI to use sessionStorage instead, which ensures that the authentication information is stored in the current browser tab alone, thereby improving security.

### Advanced I/O handling for transform FPE

The Transform Secrets Engine allows users to securely encrypt data while providing control over the output format. In Vault 1.9, we introduced [additional format fields](/vault/docs/release-notes/1.9.0#advanced-i-o-handling-for-tranform-fpe-adp-transform) on the templates used for this workflow. In Vault 1.10.0, we have now added those two new fields, `encode_format` and `decode_format`, to the Create Template page on the UI under Advanced Templating.

## Breaking changes

The following section details breaking changes introduced in Vault 1.10.0.

### LDAP auth method entity alias mapping

In Vault 1.9, we added support to provide custom user filters through the [userfilter](/vault/api-docs/auth/ldap#userfilter) parameter. This support changed the way that entity alias was mapped to an entity. Prior to Vault 1.9, alias names were always based on the [login username](/vault/api-docs/auth/ldap#username-3) (which in turn is based on the value of the [userattr](/vault/api-docs/auth/ldap#userattr)). In Vault 1.9, alias names no longer mapped to the login username. Instead, the mapping depends on other config values as well, such as [updomain](/vault/api-docs/auth/ldap#upndomain), [binddn](/vault/api-docs/auth/ldap#binddn), [discoverydn](/vault/api-docs/auth/ldap#discoverdn), and [userattr](/vault/api-docs/auth/ldap#userattr).

With Vault 1.10.0, we re-introduced the option to force the alias name to map to the login username with the optional parameter username_as_alias. Users that have the LDAP auth method enabled prior to Vault 1.9 may want to consider setting this to true to revert back to the old behavior. Otherwise, depending on the other aforementioned config values, logins may generate a new and different entity for an existing user with a previous entity associated in Vault. This in turn affects client counts since there may be more than one entity tied to this user. The username_as_alias flag was also made available in subsequent Vault 1.8.x and Vault 1.9.x releases to allow for this to be set prior to a Vault 1.10.0 upgrade.

## Known issues

### Single Vault follower restart causes election even with established quorum

We now support Server Side Consistent Tokens (See [Replication](/vault/docs/configuration/replication), [Vault Eventual Consistency](/vault/docs/enterprise/consistency), and [Upgrade to 1.10.0](/vault/docs/upgrading/upgrade-to-1.10.x).), which introduces a new token format that can only be used on nodes of 1.10 or higher version. This new format is enabled by default upon upgrading to the new version. Old format tokens can be read by Vault 1.10.0, but the new format Vault 1.10 tokens cannot be read by older Vault versions.

For more details, see the [Server Side Consistent Tokens FAQ](/vault/docs/faq/ssct).

Since service tokens are always created on the leader, as long as the leader is not upgraded before performance standbys, service tokens will be of the old format and still be usable during the upgrade process. However, the usual upgrade process we recommend can't be relied upon to always upgrade the leader last. Due to this known [issue](https://github.com/hashicorp/vault/issues/14153), a Vault cluster using Integrated Storage may result in a leader not being upgraded last, and this can trigger a re-election. This re-election can cause the upgraded node to become the leader, resulting in the newly created tokens on the leader to be unusable on nodes that have not yet been upgraded. Note that this issue does not impact Vault Community Edition users.

We will have a fix for this issue in Vault 1.10.1. Until this issue is fixed, you may be at risk of having performance standbys unable to service requests until all nodes are upgraded. We recommended that you plan for a maintenance window to upgrade.

### Limited policy shows unhelpful message in UI after mounting a secret engine

When a user has a policy that allows creating a secret engine but not reading it, after successful creation, the user sees a message `n is undefined` instead of a permissions error. We will have a fix for this issue in an upcoming minor release.

### Adding/Modifying Duo MFA method for enterprise MFA triggers a panic error

When adding or modifying a Duo MFA method for step-up Enterprise MFA using the `sys/mfa/method/duo` endpoint, a panic gets triggered due to a missing schema field. We will have a fix for this in Vault 1.10.1. Until this issue is fixed, avoid making any changes to your Duo configuration if you are upgrading Vault to v1.10.0.

### Sign in to UI using OIDC auth method results in an error

Signing in to the Vault UI using an OIDC auth mount listed in the "tabs" of the form will result
in the following error: "Authentication failed: role with oidc role_type is not allowed".
The auth mounts listed in the "tabs" of the form are those that have [listing_visibility](/vault/api-docs/system/auth#listing_visibility-1)
set to `unauth`.

There is a workaround for this error that will allow you to sign in to Vault using the OIDC
auth method. Select the "Other" tab instead of selecting the specific OIDC auth mount tab.
From there, select "OIDC" from the "Method" select box and proceed to sign in to Vault.

### Error initializing raft storage type with windows

When trying to start Vault server 1.10.0 on Windows, and there is less than 100GB of free disk space, there is an initialization error with raft DB related to insufficient space on the disk. See this [issue](https://github.com/hashicorp/vault/issues/14895) for details.  Windows users should wait till 1.10.1 to upgrade.

## Feature deprecations and EOL

Please refer to the [Deprecation Plans and Notice](/vault/docs/deprecation) page for up-to-date information on feature deprecations and plans. An [Feature Deprecation FAQ](/vault/docs/deprecation/faq) page is also available to address questions concerning decisions made about Vault feature deprecations.

layout  docs page title  1 10 0 description       This page contains release notes for Vault 1 10 0        Vault 1 10 0 release notes    Software Release date    Mar 23  2022    Summary    Vault version 1 10 0 offers features and enhancements that improve the user experience while closing the loop on key issues previously encountered by our customers  We are providing a summary of these improvements in these release notes   We encourage you to upgrade to the latest release to take advantage of the new benefits that we are providing  Additionally  with this latest release  we offer solutions to critical feature gaps that have been identified previously  For further information on product improvements  including a comprehensive list of bug fixes  please refer to the  Changelog  https   github com hashicorp vault blob main CHANGELOG md  within the Vault 1 10 0 release   Some of these enhancements and changes in this release include     Ability to view client counts per auth and changes to clients over months  therefore  providing more granular visibility into clients    Extended the  sys remount  API endpoint to support moving secrets engines and auth method mounts from one location to another  within a namespace or across namespaces    Improved security posture that includes MFA on login for Vault Community Edition customers    Ability to implicitely achieve consistency via tokens    Support of PKCE on Vault s OIDC auth method with Telemetry support for the Vault Agent    Improvement of key areas and parity to support using Terraform Provider with Vault      New features  This section describes the new features introduced as part of Vault      Multi Factor authentication  MFA  for Vault Community Edition  Vault has had support for the  Step up Enterprise MFA   vault docs enterprise mfa  as part of its Enterprise edition  The Step up Enterprise MFA allows having an MFA on login  or for step up access to sensitive resources in Vault   With Vault 1 10 0  MFA as part of  login   vault docs auth login mfa  is now supported for Vault Community Edition  This demonstrates HashiCorp s thought leadership in security and its continued endeavor to enable all Vault users to employ strong security policies with Vault        Note    The Legacy MFA in Vault Community Edition is a  deprecated   vault docs deprecation  feature and will be removed in Vault 1 11   Refer to the  Login MFA FAQ   vault docs auth login mfa faq  to understand the various MFA workflows that are supported in Vault 1 10 0       Vault OIDC provider with PKCE support  Vault s support to act as an OIDC provider is now generally available  Furthermore  Vault s OIDC provider functionality can now support PKCE for authorization code flow as well  Thanks to all the excellent community feedback received  we have simplified the user experience around configuration of OIDC provider functionality       Caching support for Vault lambda extension  With 0 6 0  Vault Lambda Extension supports  caching  https   github com hashicorp vault lambda extension caching  in the local proxy server to avoid proxying every request to enable setting expiry time and invalidate cache  as needed       Terraform provider for Vault  We have introduced three new resources to enable configuration of the  KMIP secrets engine  https   registry terraform io providers hashicorp vault latest docs resources kmip secret backend  using the Terraform Provider for Vault  In addition  frequent releases on the Terraform Provider for Vault have been incorporating the ability to configure newer resources and data sources  Please read the  documentation  https   registry terraform io providers hashicorp vault latest docs  for more details       KV secrets engine v2 patch operations  We now support an additional method for managing  KV v2 secrets   vault api docs secret kv kv v2  to maintain least privilege security in certain types of automated environments  This feature creates a new PATCH capability that enables partial updates to KV v2 secrets without requiring the READ privilege to the entire endpoint for an entity       DB2 dynamic secrets support  Vault operators can leverage the openldap secrets engine to manage credentials for IBM DB2 and the LDAP security plugin for Db2  This allows Db2 to offload authentication and authorization to the LDAP security plugin and allows Vault to manage static credentials or even generate dynamic users  For more details  refer to the For more details  refer to the  IBM Db2 Credentials Management   vault tutorials secrets management ibm db2 openldap  tutorial       Temporal transit key rotation  Proper key management includes occasionally rotating encryption keys to reduce the risks of a nonce reuse and opportunities for keys to be compromised  Previously  there was no automated way to rotate keys that is native to Vault  Now  we have provided a new configuration element on transit keys and tokenization transform configurations where a time interval triggers the keys to automatically rotate after the interval has lapsed       PKI HSM forwarding  To address security and compliance needs  customers may require that keys be either created or stored within Hardware Security Models  HSMs   Vault 1 10 0 introduces an accommodation for this requirement with regards to the PKI Secrets Engine  We now support offloading selected PKI operations to HSMs  in particular allowing customers to both generate new PKI key pairs and sign verify some certificate workflows  All of these operations are conducted in a way that never allows the private key material to leave the secure confines of the HSM itself       AWS and AKV KMS forwarding  The work done above to support HSM backed PKI operations inspired us to consider what other key possession paradigms we could support  This led us to extend the implementation to support Cloud Key Management Systems in addition to HSMs  In Vault 1 10 0  users may generate new PKI pairs and perform sign verify certificate workflows  all with those keys never leaving the cloud KMS itself  Vault 1 10 0 provides support for AWS Key Management Service and Azure Key Vault Key Management Service       Server side consistent tokens  Vault s  eventual consistency   vault docs enterprise consistency  model precludes read after write guarantees when clients interact with performance standbys or performance replication clusters  The  Client Controlled Consistency   vault docs enterprise consistency vault 1 7 mitigations  mitigations supported with Vault 1 7 provide ways to achieve consistency through client modifications or by using the agent for proxied requests  which is not possible in all cases  The Server Side Consistent Tokens feature provides an implicit way to achieve consistency by embedding the minimum Write Ahead Log state information in the Service tokens returned from logins or token create requests  This feature introduces changes in the token format and the new tokesn will be the default tokens starting in Vault 1 10 0  Vault 1 10 0 is backwards compatible with old tokens   See  Replication   vault docs configuration replication    Vault Eventual Consistency   vault docs enterprise consistency    Upgrade to 1 10 0   vault docs upgrading upgrade to 1 10 x  and  Server Side Consistent Token FAQ   vault docs faq ssct  to understand the various consistency options available with Vault 1 10 0 and the considerations to be aware of prior to selecting an option for your use case      Vault agent features      Support for telemetry  Starting with Vault 1 10 0  the Vault Agent supports a new metrics endpoint and  Telemetry   vault docs agent telemetry stanza  metrics around run time  authentication success  authentication failures  cache hits  cache misses  proxy succes  and proxy client errors  This Vault Agent Telemetry should greatly help with the retrieval of key operational insights for Vault Agent deployments       User assigned managed identities for auto auth in Azure  With this  enhancement   vault docs agent autoauth methods azure   users can specify user assigned managed identities via the  object id  and  client id  when configuring Vault agent auto auth for Azure  This enables users that have more than one user assigned managed identity associated with their VM to specify which one they d like to use when authenticating via the Vault s Azure auth method  Note that providing these parameters is an  exclusive or  operation       Quit API endpoint with config  Previously  for instances where the Agent is a sidecar in a Kubernetes job and the job hangs  you must either use  shareProcessNamespace  true  for the container so that the process kill signals can be sent  or avoid the sidecar container entirely and solely rely on an init container  With this  enhancement   vault docs agent quit   we have added support for a Quit API endpoint to automatically shut down the Vault Agent  therefore eliminating the need to perform the workarounds      Other features and enhancements  This section describes other features and enhancements introduced as part of the Vault 1 10 0 release       Client count improvements  We have introduced auth mount based attribution of clients to help better understand where clients are being used within a cluster  This is available via UI and API  This is an enhancement on top of the namespace attribution capability we introduced in Vault 1 9   We have also introduced the ability to view changes to clients month over month via the client count API  and made other UI enhancements  Refer to  What is a Client    vault docs concepts client count  and  Client Count FAQ   vault docs concepts client count faq  for more details       Mount migration  We have made improvements to the  sys remount  API endpoint to simplify the complexities of moving data  such as secret engine and authentication method configuration from one mount to another  within a namespace or across namespaces  This can help with restructuring namespaces and mounts for various reasons  including migrating mounts from root to other namespaces when transitioning to using namespaces for the first time  For step by step instructions  refer to the  Mount Move   vault tutorials enterprise mount move  tutorial       Scaling external database plugins  Database plugins can now implement  plugin multiplexing   vault docs plugins plugin architecture plugin multiplexing  which allows a single plugin process to be used for multiple database connections  Database plugin multiplexing will be enabled on the Oracle Database plugin starting in v0 6 0  We will extend this functionality to additional database plugins in subsequent releases   Any external database plugins that want to adopt multiplexing support will have to update their main go call from  dbplugin Serve    https   github com hashicorp vault blob sdk v0 4 1 sdk database dbplugin v5 plugin server go L13  to  dbplugin ServeMultiplex    https   github com hashicorp vault blob sdk v0 4 1 sdk database dbplugin v5 plugin server go L42   Multiplexable database plugins are compatible with older versions of Vault down to Vault 1 6  Refer to this  Oracle Database PR  https   github com hashicorp vault plugin database oracle pull 74  as an example of the upgrade process       Consul secrets engine enhancements  Consul has supported  namespace   consul docs enterprise namespaces    admin partitions   consul docs enterprise admin partitions  and  ACL roles   consul commands acl role  for some time now  In this release we have added enhancements to the Consul Secrets engine to support namespace awareness and add admin partition and role support for Consul ACL tokens  This significantly simplifies the integrations for customers who want to achieve a zero trust security posture with both Vault and Consul       Using sessionStorage instead of localStorage for the Vault UI  Prior to Vault 1 10 0  the Vault UI used localStorage to store authentication information  The data in localStorage was persisted in browsers and removed only on demand  Now  we have switched the Vault UI to use sessionStorage instead  which ensures that the authentication information is stored in the current browser tab alone  thereby improving security       Advanced I O handling for transform FPE  The Transform Secrets Engine allows users to securely encrypt data while providing control over the output format  In Vault 1 9  we introduced  additional format fields   vault docs release notes 1 9 0 advanced i o handling for tranform fpe adp transform  on the templates used for this workflow  In Vault 1 10 0  we have now added those two new fields   encode format  and  decode format   to the Create Template page on the UI under Advanced Templating      Breaking changes  The following section details breaking changes introduced in Vault 1 10 0       LDAP auth method entity alias mapping  In Vault 1 9  we added support to provide custom user filters through the  userfilter   vault api docs auth ldap userfilter  parameter  This support changed the way that entity alias was mapped to an entity  Prior to Vault 1 9  alias names were always based on the  login username   vault api docs auth ldap username 3   which in turn is based on the value of the  userattr   vault api docs auth ldap userattr    In Vault 1 9  alias names no longer mapped to the login username  Instead  the mapping depends on other config values as well  such as  updomain   vault api docs auth ldap upndomain    binddn   vault api docs auth ldap binddn    discoverydn   vault api docs auth ldap discoverdn   and  userattr   vault api docs auth ldap userattr    With Vault 1 10 0  we re introduced the option to force the alias name to map to the login username with the optional parameter username as alias  Users that have the LDAP auth method enabled prior to Vault 1 9 may want to consider setting this to true to revert back to the old behavior  Otherwise  depending on the other aforementioned config values  logins may generate a new and different entity for an existing user with a previous entity associated in Vault  This in turn affects client counts since there may be more than one entity tied to this user  The username as alias flag was also made available in subsequent Vault 1 8 x and Vault 1 9 x releases to allow for this to be set prior to a Vault 1 10 0 upgrade      Known issues      Single Vault follower restart causes election even with established quorum  We now support Server Side Consistent Tokens  See  Replication   vault docs configuration replication    Vault Eventual Consistency   vault docs enterprise consistency   and  Upgrade to 1 10 0   vault docs upgrading upgrade to 1 10 x     which introduces a new token format that can only be used on nodes of 1 10 or higher version  This new format is enabled by default upon upgrading to the new version  Old format tokens can be read by Vault 1 10 0  but the new format Vault 1 10 tokens cannot be read by older Vault versions   For more details  see the  Server Side Consistent Tokens FAQ   vault docs faq ssct    Since service tokens are always created on the leader  as long as the leader is not upgraded before performance standbys  service tokens will be of the old format and still be usable during the upgrade process  However  the usual upgrade process we recommend can t be relied upon to always upgrade the leader last  Due to this known  issue  https   github com hashicorp vault issues 14153   a Vault cluster using Integrated Storage may result in a leader not being upgraded last  and this can trigger a re election  This re election can cause the upgraded node to become the leader  resulting in the newly created tokens on the leader to be unusable on nodes that have not yet been upgraded  Note that this issue does not impact Vault Community Edition users   We will have a fix for this issue in Vault 1 10 1  Until this issue is fixed  you may be at risk of having performance standbys unable to service requests until all nodes are upgraded  We recommended that you plan for a maintenance window to upgrade       Limited policy shows unhelpful message in UI after mounting a secret engine  When a user has a policy that allows creating a secret engine but not reading it  after successful creation  the user sees a message  n is undefined  instead of a permissions error  We will have a fix for this issue in an upcoming minor release       Adding Modifying Duo MFA method for enterprise MFA triggers a panic error  When adding or modifying a Duo MFA method for step up Enterprise MFA using the  sys mfa method duo  endpoint  a panic gets triggered due to a missing schema field  We will have a fix for this in Vault 1 10 1  Until this issue is fixed  avoid making any changes to your Duo configuration if you are upgrading Vault to v1 10 0       Sign in to UI using OIDC auth method results in an error  Signing in to the Vault UI using an OIDC auth mount listed in the  tabs  of the form will result in the following error   Authentication failed  role with oidc role type is not allowed   The auth mounts listed in the  tabs  of the form are those that have  listing visibility   vault api docs system auth listing visibility 1  set to  unauth    There is a workaround for this error that will allow you to sign in to Vault using the OIDC auth method  Select the  Other  tab instead of selecting the specific OIDC auth mount tab  From there  select  OIDC  from the  Method  select box and proceed to sign in to Vault       Error initializing raft storage type with windows  When trying to start Vault server 1 10 0 on Windows  and there is less than 100GB of free disk space  there is an initialization error with raft DB related to insufficient space on the disk  See this  issue  https   github com hashicorp vault issues 14895  for details   Windows users should wait till 1 10 1 to upgrade      Feature deprecations and EOL  Please refer to the  Deprecation Plans and Notice   vault docs deprecation  page for up to date information on feature deprecations and plans  An  Feature Deprecation FAQ   vault docs deprecation faq  page is also available to address questions concerning decisions made about Vault feature deprecations


vault Software Release date Oct 12 2022 Vault 1 12 0 release notes layout docs page title 1 12 0 This page contains release notes for Vault 1 12 0

Answer:
---
layout: docs
page_title: 1.12.0
description: |-
  This page contains release notes for Vault 1.12.0
---

# Vault 1.12.0 release notes

**Software Release date:** Oct. 12, 2022

**Summary:** Vault Release 1.12.0 offers features and enhancements that improve the user experience while solving critical  issues previously encountered by our customers. We are providing an overview  of improvements in this set of  release notes.

We encourage you to upgrade to the latest release of Vault to take advantage of the new benefits provided. With this latest release, we offer solutions to critical feature gaps that were identified previously. Please refer to the [Changelog](https://github.com/hashicorp/vault/blob/main/CHANGELOG.md) within the Vault release for further information on product improvements, including a comprehensive list of bug fixes.

Some of these enhancements and changes in this release include the following:

- Vault Enterprise now supports **PKCS#11** provider plugin (client library) functionality.
- Vault Enterprise can manage keys for **Oracle TDE**. This requires the Advanced Data Protection license.
- **PKI Key revocation** improvements are made to Vault’s PKI engine, introducing a new OCSP responder and automatic CRL rebuilding (with up-to-date Delta CRL), that offers significant performance and data transfer improvements to revocation workflows.
- **BYOK in Transform engines** now allow users to import their keys generated elsewhere.
- **KMIP Server Profile** adds support for additional operations, allowing  Vault to claim support for the baseline server profile.
- **Transform secrets engine** supports time-based auto-key rotation for tokenization.
- **Path and Role-based Quotas** extend the existing Vault Quota support by allowing quotas to be extended to the API path suffixes and auth mount roles.
- **Licensing** termination behavior has changed where non-evaluation licenses (production licenses) will no longer have a termination date.
- **Redis Database Secrets Engine** is now available to manage static roles or generation of dynamic credentials, as well as root credential rotation on a stand-alone Redis server.
- **AWS Elasticache Database Secrets Engine** is introduced to manage static credentials for AWS Elasticache instances.

~> **Vault Enterprise:** Use [Integrated Storage](/vault/docs/configuration/storage/raft) or [Consul](/vault/docs/configuration/storage/consul) as your Vault's storage backend. Vault Enterprise will no longer start up if configured to use a storage backend other than Integrated Storage or Consul. (See the [Upgrade Guide](/vault/docs/upgrading/upgrade-to-1.12.x).)

## New features

This section describes the new features introduced in Vault 1.12.0.

### Transform secrets engine enhancements

-> **NOTE:** These features need the Vault Enterprise ADP License.

#### Bring your own key (BYOK) for transform

In release 1.11, we introduced BYOK support to Vault, enabling  customers to import existing keys into the Vault Transit Secrets Engine and  enabling secure and flexible Vault deployments.
We  are extending that support to the Vault Transform Secrets Engine in this release.

#### MSSQL support

An MSSQL store is now available to be used as an external storage engine with tokenization Transform Secrets Engine. Refer to the following documents, [Transform Secrets Engine(API)](/vault/api-docs/secret/transform), [Transform Secrets Engine](/vault/docs/secrets/transform), and [Tokenization Transform](/vault/docs/secrets/transform/tokenization) for more information.

#### Key auto rotation

Periodic rotation of encryption keys is a recommended key management practice for a good security posture. In Vault release 1.10, we added support for Auto key rotation for Transit Secrets Engine. In Vault 1.12, the Transform secrets engine is now  enhanced, allowing users to set the rotation policy during key creation in a time interval, which will cause Vault to rotate the Transform keys when the time interval elapses automatically.

Refer to the following documentation [Tokenization Transform](/vault/docs/secrets/transform/tokenization) and [Transform Secrets Engine(API)](/vault/api-docs/secret/transform#rotate-tokenization-key) for more information.

### PKI secrets engine improvements

#### PKI secrets engine revocation enhancements

We are improving Vault PKI Engine’s revocation capabilities by adding support for the Online Certificate Status Protocol (OCSP) and a delta Certificate Revocation List (CRL) to track changes to the main CRL. These enhancements significantly streamline customer experience with the PKI engine making the certification revocation semantics easier to understand and manage. Additionally, support for automatic CRL rotation and periodic tidy operations help reduce operator burden, alleviate the demand on cluster resources during periods of high revocation, and ensure clients are always served valid CRLs. Finally, support for Bring-Your-Own-Cert (BYOC) allows revocation of `no_store=true` certificates and for Proof-of-Possession (PoP) allows end-users to safely revoke their own certificates (with corresponding private key) without operator intervention.

#### PKI and managed key support for RSA-PSS signatures

Since its initial release, Vault's PKI secrets engine only supported RSA-PKCS#1v1.5 (Public Key Cryptographic Standards) signatures for issuers and leaves. To conform with NIST's guidance around key transport and for compatibility with newer HSM Firmware, we have included support for RSA-PSS signatures (Probabilistic Signature Scheme). See the section on [PSS Support in the PKI documentation](/vault/docs/secrets/pki/considerations#pss-support) for limitations of this feature.

#### PKI telemetry improvements

In this release, we are adding additional telemetry to Vault’s PKI secrets engine, enabling customers to gather better  insights into  certificate usage via the count of stored and revoked certificates. Additionally, the Vault `tidy` function is enhanced with additional metrics that reflect the remaining stored and revoked certificates.

#### Auto-fetch CRL in the certificate auth method

Operators will now be able to specify one or more CRL URLs that Vault will automatically fetch and keep up-to-date, rather than having to push the CRLs to the cert auth method. This should make certificate management easier for those users that have large cert auth deployments.

#### GCP Cloud key manager support

Managed Keys let Vault secrets engines (currently PKI) use keys stored in Cloud KMS systems for cryptographic operations like certificate signing.  Vault 1.12 adds support for GCP Cloud KMS to the Managed Key system, where previously AWS, Azure, and PKCS#11 Hardware Security Modules were supported.

### KMIP server profile

The [Baseline Server Profile](https://docs.oasis-open.org/kmip/kmip-profiles/v2.1/os/kmip-profiles-v2.1-os.html) specifies the basic functionality expected of a KMIP server.  In Vault 1.12, we offer support for the operations and attributes in the Baseline server profile. With this release, Vault Enterprise now supports the Symmetric Key lifecycle server profile, Baseline server profile, and the Basic Cryptographic server profile (as of Release 1.11), enabling the  support of KMIP integrations with various clients more effectively. This requires the Vault Enterprise ADP license.

### SSH secrets engine support for generating keys

Previously, Vault's SSH Secrets Engine when used as an SSH CA required requesters to provide their own public key for signing. In Vault 1.12, Vault can now generate credential key pairs dynamically, returning them to the requester.

This was a community contributed enhancement.

### Path and Role-Based resource quotas

In this release, the existing resource quota functionality has been enhanced. In addition to applying the API rate limiting and lease quotas at the namespace or mount level, you can now use  the quotas to the [API path suffixes and auth mount roles](/vault/docs/enterprise/lease-count-quotas). This enhancement provides users with more control over issued certificates.

### Client count improvements

The billing period for client counting API can now be specified with the [current month](/vault/docs/concepts/client-count) for the end date parameter. When this is done the "new_clients" field will have an hyperlog approximate value indicating the number of new clients that came in the current month. Note that for the previous months, the number will be an exact value.

### Redis database secrets engine

With the support of the Redis database secrets engine, users can use Vault to manage static and dynamic credentials for Redis OSS. The engine  works similarly to other database secrets engines. Refer to the [Redis](/vault/docs/secrets/databases/redis) documentation for more information. Huge thanks to [Francis Hitchens](https://github.com/fhitchen), who contributed their repository to HashiCorp

### AWS elasticache database secrets engine
With the support of the AWS ElastiCache database secrets engine, users may use Vault to manage static credentials for AWS Elasticache instances. The engine will work similarly to other database secrets engines. Refer to the [elasticache](/vault/docs/secrets/databases/rediselasticache) documentation for more information.

### LDAP secrets engine

Vault 1.12 introduces a new LDAP secrets engine that unifies the user experience between the Active Directory (AD) secrets engine and OpenLDAP secrets engine. This new engine simplifies the user experience when Vault is used to manage credentials for directory services. This new engine supports all implementations from both of the engines mentioned above (AD, LDAP and RACF) and brings dynamic credential capabilities for users relying on Active Directory.

~> **Note:** This engine does _not_ replace the current Active Directory secrets engine. We will continue to maintain the engine and provide bug fixes, but encourage all new users to use the unified LDAP engine. We will communicate the schedule to deprecate the Active Directory secrets engine well in advance, providing time for users to migrate over.

### Terraform Vault provider: Vault version detection

Vault Terraform provider v3.9.0 can now query Vault to detect the server’s version of the server and then perform a semantic version comparison against a provided minimum threshold version to determine whether a selected feature is available for use. This allows for the Vault provider to deterministically anticipate Vault’s behavior.

### Plugin versioning

In prior versions of Vault, plugins were not “version-aware,”  creating a suboptimal user experience during plugin installation and upgrades. In Vault 1.12, we are introducing the concept of versions to plugins, making plugins “version-aware” and allowing standardization of the release processes and offering a better user experience when installing and upgrading plugins.

### PKCS#11 client support

Software solutions often require cryptographic objects-like keys, X.509 certificates, or perform operations like a certificate or key generation, hashing, encryption, decryption, and signing. Hardware Security Modules (HSM) are traditionally used as a secure option, but are expensive and challenging to operationalize.

Vault Enterprise 1.12 is a PKCS#11 2.40 compliant provider, extended profile. PKCS#11 is the standard protocol supported for integrating with HSMs. Support for this protocol is the first step to enabling customers to consolidate HSMs. It also has the operational flexibility and advantages of software for key generation, encryption, and object storage operations. The PKCS#11 support in Vault 1.12 supports a subset of key generation, encryption, decryption and key storage operations. This requires the Enterprise ADP-KM license.

~> **Note:** With this feature, Vault does not become an HSM. HSMs are needed where customer use cases need FIPS 140-2 L2+ compliance support.

### Oracle TDE

With Vault 1.12, Vault Enterprise (ADP-KM) can now act as an external key manager for Oracle instances when Transparent Data Encryption is enabled. TDE allows users to conjure and use Vault to protect their Data Encryption Keys by using Vault to protect them using a Key Encryption Key. Reading and writing of data securely are handled transparently by Oracle database instances without needing user intervention. This will need the Enterprise ADP license.

### UI support for okta number challenge

In Vault 1.11, we added support for Okta’s Number Challenge feature in the CLI and API. In Vault 1.12, we’ve extended this support to the Vault UI, allowing users to complete the Okta Number Challenge from a web browser, the command line, and the HTTP API.

### OIDC provider support in the UI
Vault can now act as an OIDC provider for applications that wish to delegate authentication to Vault and leverage its identity system. As an OIDC provider, Vault supports PKCE for authorization code flow, preventing attacks such as SSRF. After OIDC provider functionality went GA, our design and user research team gathered feedback from community members, and we simplified the setup experience. With a few CLI commands or UI clicks, users can now have a default OIDC provider with its defaults configured and ready to go for applications to utilize the functionality.

## Other features and enhancements

### License termination behavior

The Licensing termination behavior has changed where non-evaluation licenses (production licenses) no longer have a termination date, making Vault more robust for Vault Enterprise customers. Also refer to the updated [licensing FAQ](/vault/docs/enterprise/license/faq) for more information.

### Namespace custom metadata
Customers can now specify [custom metadata](/vault/api-docs/system/namespaces) on the namespaces. The new `vault namespace patch` [command](/vault/docs/commands/namespace) can be used to update existing namespaces with custom metadata as well. This will make it possible to tag namespaces with additional fields (For example: owner, region department) describing it.

### Vault agent improvements

Vault Agent introduced new configuration parameters that will significantly improve the use of Vault Agent. These includes:

- Added `disable_idle_connections` configuration to disable leaving idle connections open in auto-auth, caching and templating.
- Added `disable_keep_alives` configuration to disable keep alives in auto-auth, caching and templating.
- JWT auto-auth now supports a `remove_jwt_after_reading` configuration option which defaults to true.

## Known issues

There are no known issues documented for this release.

## Feature deprecations and EOL

Please refer to the [Deprecation Plans and Notice](/vault/docs/deprecation) page for up-to-date information on feature deprecations and plans. A [Feature Deprecation FAQ](/vault/docs/deprecation/faq) page addresses questions about  decisions made about Vault feature deprecations.

layout  docs page title  1 12 0 description       This page contains release notes for Vault 1 12 0        Vault 1 12 0 release notes    Software Release date    Oct  12  2022    Summary    Vault Release 1 12 0 offers features and enhancements that improve the user experience while solving critical  issues previously encountered by our customers  We are providing an overview  of improvements in this set of  release notes   We encourage you to upgrade to the latest release of Vault to take advantage of the new benefits provided  With this latest release  we offer solutions to critical feature gaps that were identified previously  Please refer to the  Changelog  https   github com hashicorp vault blob main CHANGELOG md  within the Vault release for further information on product improvements  including a comprehensive list of bug fixes   Some of these enhancements and changes in this release include the following      Vault Enterprise now supports   PKCS 11   provider plugin  client library  functionality    Vault Enterprise can manage keys for   Oracle TDE    This requires the Advanced Data Protection license      PKI Key revocation   improvements are made to Vault s PKI engine  introducing a new OCSP responder and automatic CRL rebuilding  with up to date Delta CRL   that offers significant performance and data transfer improvements to revocation workflows      BYOK in Transform engines   now allow users to import their keys generated elsewhere      KMIP Server Profile   adds support for additional operations  allowing  Vault to claim support for the baseline server profile      Transform secrets engine   supports time based auto key rotation for tokenization      Path and Role based Quotas   extend the existing Vault Quota support by allowing quotas to be extended to the API path suffixes and auth mount roles      Licensing   termination behavior has changed where non evaluation licenses  production licenses  will no longer have a termination date      Redis Database Secrets Engine   is now available to manage static roles or generation of dynamic credentials  as well as root credential rotation on a stand alone Redis server      AWS Elasticache Database Secrets Engine   is introduced to manage static credentials for AWS Elasticache instances         Vault Enterprise    Use  Integrated Storage   vault docs configuration storage raft  or  Consul   vault docs configuration storage consul  as your Vault s storage backend  Vault Enterprise will no longer start up if configured to use a storage backend other than Integrated Storage or Consul   See the  Upgrade Guide   vault docs upgrading upgrade to 1 12 x        New features  This section describes the new features introduced in Vault 1 12 0       Transform secrets engine enhancements       NOTE    These features need the Vault Enterprise ADP License        Bring your own key  BYOK  for transform  In release 1 11  we introduced BYOK support to Vault  enabling  customers to import existing keys into the Vault Transit Secrets Engine and  enabling secure and flexible Vault deployments  We  are extending that support to the Vault Transform Secrets Engine in this release        MSSQL support  An MSSQL store is now available to be used as an external storage engine with tokenization Transform Secrets Engine  Refer to the following documents   Transform Secrets Engine API    vault api docs secret transform    Transform Secrets Engine   vault docs secrets transform   and  Tokenization Transform   vault docs secrets transform tokenization  for more information        Key auto rotation  Periodic rotation of encryption keys is a recommended key management practice for a good security posture  In Vault release 1 10  we added support for Auto key rotation for Transit Secrets Engine  In Vault 1 12  the Transform secrets engine is now  enhanced  allowing users to set the rotation policy during key creation in a time interval  which will cause Vault to rotate the Transform keys when the time interval elapses automatically   Refer to the following documentation  Tokenization Transform   vault docs secrets transform tokenization  and  Transform Secrets Engine API    vault api docs secret transform rotate tokenization key  for more information       PKI secrets engine improvements       PKI secrets engine revocation enhancements  We are improving Vault PKI Engine s revocation capabilities by adding support for the Online Certificate Status Protocol  OCSP  and a delta Certificate Revocation List  CRL  to track changes to the main CRL  These enhancements significantly streamline customer experience with the PKI engine making the certification revocation semantics easier to understand and manage  Additionally  support for automatic CRL rotation and periodic tidy operations help reduce operator burden  alleviate the demand on cluster resources during periods of high revocation  and ensure clients are always served valid CRLs  Finally  support for Bring Your Own Cert  BYOC  allows revocation of  no store true  certificates and for Proof of Possession  PoP  allows end users to safely revoke their own certificates  with corresponding private key  without operator intervention         PKI and managed key support for RSA PSS signatures  Since its initial release  Vault s PKI secrets engine only supported RSA PKCS 1v1 5  Public Key Cryptographic Standards  signatures for issuers and leaves  To conform with NIST s guidance around key transport and for compatibility with newer HSM Firmware  we have included support for RSA PSS signatures  Probabilistic Signature Scheme   See the section on  PSS Support in the PKI documentation   vault docs secrets pki considerations pss support  for limitations of this feature        PKI telemetry improvements  In this release  we are adding additional telemetry to Vault s PKI secrets engine  enabling customers to gather better  insights into  certificate usage via the count of stored and revoked certificates  Additionally  the Vault  tidy  function is enhanced with additional metrics that reflect the remaining stored and revoked certificates        Auto fetch CRL in the certificate auth method  Operators will now be able to specify one or more CRL URLs that Vault will automatically fetch and keep up to date  rather than having to push the CRLs to the cert auth method  This should make certificate management easier for those users that have large cert auth deployments        GCP Cloud key manager support  Managed Keys let Vault secrets engines  currently PKI  use keys stored in Cloud KMS systems for cryptographic operations like certificate signing   Vault 1 12 adds support for GCP Cloud KMS to the Managed Key system  where previously AWS  Azure  and PKCS 11 Hardware Security Modules were supported       KMIP server profile  The  Baseline Server Profile  https   docs oasis open org kmip kmip profiles v2 1 os kmip profiles v2 1 os html  specifies the basic functionality expected of a KMIP server   In Vault 1 12  we offer support for the operations and attributes in the Baseline server profile  With this release  Vault Enterprise now supports the Symmetric Key lifecycle server profile  Baseline server profile  and the Basic Cryptographic server profile  as of Release 1 11   enabling the  support of KMIP integrations with various clients more effectively  This requires the Vault Enterprise ADP license       SSH secrets engine support for generating keys  Previously  Vault s SSH Secrets Engine when used as an SSH CA required requesters to provide their own public key for signing  In Vault 1 12  Vault can now generate credential key pairs dynamically  returning them to the requester   This was a community contributed enhancement       Path and Role Based resource quotas  In this release  the existing resource quota functionality has been enhanced  In addition to applying the API rate limiting and lease quotas at the namespace or mount level  you can now use  the quotas to the  API path suffixes and auth mount roles   vault docs enterprise lease count quotas   This enhancement provides users with more control over issued certificates       Client count improvements  The billing period for client counting API can now be specified with the  current month   vault docs concepts client count  for the end date parameter  When this is done the  new clients  field will have an hyperlog approximate value indicating the number of new clients that came in the current month  Note that for the previous months  the number will be an exact value       Redis database secrets engine  With the support of the Redis database secrets engine  users can use Vault to manage static and dynamic credentials for Redis OSS  The engine  works similarly to other database secrets engines  Refer to the  Redis   vault docs secrets databases redis  documentation for more information  Huge thanks to  Francis Hitchens  https   github com fhitchen   who contributed their repository to HashiCorp      AWS elasticache database secrets engine With the support of the AWS ElastiCache database secrets engine  users may use Vault to manage static credentials for AWS Elasticache instances  The engine will work similarly to other database secrets engines  Refer to the  elasticache   vault docs secrets databases rediselasticache  documentation for more information       LDAP secrets engine  Vault 1 12 introduces a new LDAP secrets engine that unifies the user experience between the Active Directory  AD  secrets engine and OpenLDAP secrets engine  This new engine simplifies the user experience when Vault is used to manage credentials for directory services  This new engine supports all implementations from both of the engines mentioned above  AD  LDAP and RACF  and brings dynamic credential capabilities for users relying on Active Directory        Note    This engine does  not  replace the current Active Directory secrets engine  We will continue to maintain the engine and provide bug fixes  but encourage all new users to use the unified LDAP engine  We will communicate the schedule to deprecate the Active Directory secrets engine well in advance  providing time for users to migrate over       Terraform Vault provider  Vault version detection  Vault Terraform provider v3 9 0 can now query Vault to detect the server s version of the server and then perform a semantic version comparison against a provided minimum threshold version to determine whether a selected feature is available for use  This allows for the Vault provider to deterministically anticipate Vault s behavior       Plugin versioning  In prior versions of Vault  plugins were not  version aware    creating a suboptimal user experience during plugin installation and upgrades  In Vault 1 12  we are introducing the concept of versions to plugins  making plugins  version aware  and allowing standardization of the release processes and offering a better user experience when installing and upgrading plugins       PKCS 11 client support    Software solutions often require cryptographic objects like keys  X 509 certificates  or perform operations like a certificate or key generation  hashing  encryption  decryption  and signing  Hardware Security Modules  HSM  are traditionally used as a secure option  but are expensive and challenging to operationalize   Vault Enterprise 1 12 is a PKCS 11 2 40 compliant provider  extended profile  PKCS 11 is the standard protocol supported for integrating with HSMs  Support for this protocol is the first step to enabling customers to consolidate HSMs  It also has the operational flexibility and advantages of software for key generation  encryption  and object storage operations  The PKCS 11 support in Vault 1 12 supports a subset of key generation  encryption  decryption and key storage operations  This requires the Enterprise ADP KM license        Note    With this feature  Vault does not become an HSM  HSMs are needed where customer use cases need FIPS 140 2 L2  compliance support       Oracle TDE  With Vault 1 12  Vault Enterprise  ADP KM  can now act as an external key manager for Oracle instances when Transparent Data Encryption is enabled  TDE allows users to conjure and use Vault to protect their Data Encryption Keys by using Vault to protect them using a Key Encryption Key  Reading and writing of data securely are handled transparently by Oracle database instances without needing user intervention  This will need the Enterprise ADP license       UI support for okta number challenge  In Vault 1 11  we added support for Okta s Number Challenge feature in the CLI and API  In Vault 1 12  we ve extended this support to the Vault UI  allowing users to complete the Okta Number Challenge from a web browser  the command line  and the HTTP API       OIDC provider support in the UI Vault can now act as an OIDC provider for applications that wish to delegate authentication to Vault and leverage its identity system  As an OIDC provider  Vault supports PKCE for authorization code flow  preventing attacks such as SSRF  After OIDC provider functionality went GA  our design and user research team gathered feedback from community members  and we simplified the setup experience  With a few CLI commands or UI clicks  users can now have a default OIDC provider with its defaults configured and ready to go for applications to utilize the functionality       Other features and enhancements      License termination behavior  The Licensing termination behavior has changed where non evaluation licenses  production licenses  no longer have a termination date  making Vault more robust for Vault Enterprise customers  Also refer to the updated  licensing FAQ   vault docs enterprise license faq  for more information       Namespace custom metadata Customers can now specify  custom metadata   vault api docs system namespaces  on the namespaces  The new  vault namespace patch   command   vault docs commands namespace  can be used to update existing namespaces with custom metadata as well  This will make it possible to tag namespaces with additional fields  For example  owner  region department  describing it       Vault agent improvements  Vault Agent introduced new configuration parameters that will significantly improve the use of Vault Agent  These includes     Added  disable idle connections  configuration to disable leaving idle connections open in auto auth  caching and templating    Added  disable keep alives  configuration to disable keep alives in auto auth  caching and templating    JWT auto auth now supports a  remove jwt after reading  configuration option which defaults to true        Known issues  There are no known issues documented for this release      Feature deprecations and EOL  Please refer to the  Deprecation Plans and Notice   vault docs deprecation  page for up to date information on feature deprecations and plans  A  Feature Deprecation FAQ   vault docs deprecation faq  page addresses questions about  decisions made about Vault feature deprecations