HashiCorp Vault 1.10 Adds Login MFA, PKI to Use HSMs, Usage Metrics, and More

We are pleased to announce the general availability of HashiCorp Vault 1.10. Vault provides secrets management, data encryption, and identity management for any application on any infrastructure.

Vault 1.10 focuses on improving Vault’s core workflows and making key features production-ready to better serve your use cases. In this release, Vault adds login multi-factor authentication (MFA) support, promotes Vault as an OIDC provider to generally available status, adds support for public key infrastructure (PKI) to use hardware security modules (HSM), and many other improvements across the project.

This release includes several key features and improvements:

• Login MFA: Added an open source login multi-factor authentication integration for additional authentication using time-based one-time password (TOTP), Okta, Duo, and PingIdentity.
• Vault as an OIDC provider: Support for Vault to act as an OIDC provider is now generally available. This lets users leverage pre-existing Vault identities for authN into their applications.
• IBM Db2 credential management: Added a HashiCorp Learn guide for handling both static and dynamic credentials for access to IBM Db2 using the OpenLDAP secrets engine.
• Database plugin multiplexing: Added process multiplexing support for database plugins so that a single plugin process can be used for multiple database connections, greatly reducing memory consumption. The Oracle database plugin is the first to leverage this capability.
• Telemetry added to Vault Agent: Added runtime metrics for Vault Agent for auth, cache, and proxy counters. Review the Telemetry Metrics Reference to learn more.
• Server-side consistent tokens: Updated token format to enable greater control over the consistency model, allowing performance standby nodes to decide whether to forward requests.
• PKI gets hardware security modules (HSM) support: Added support for the PKI secrets engine to offload key generation and certificate signing to an HSM. PKCS#11 HSMs, Azure Key Vault, and AWS KMS are supported.
• Auto-key rotation for Transit: Added support encryption key auto-rotation to Transit secrets engine via an auto_rotate_period configuration option.
• Vault usage metrics: Enhanced the usage metrics dashboard so that you can more easily select a billing period. In addition, you can view client count per auth mount. Added support to the API for viewing client changes month over month.
• User interface updates: Updated Transform secrets engine UI with advanced I/O handling for Transform FPE.
• Move secrets engines and auth methods: Extended the sys/remount API endpoint to support moving secrets engines and auth methods’ mounts from one location to another and across namespaces.

This release also includes more new features, workflow enhancements, general improvements, and bug fixes. The Vault 1.10 changelog and release notes list all the changes. Please visit the Vault HashiCorp Learn page for step-by-step tutorials demonstrating the new features.

»Login Multi-Factor Authentication

We strongly believe that MFA offers additional protections that should be accessible to everyone because it provides stronger protection for accounts in the event of compromised credentials. We have supported MFA in the Enterprise version of Vault for several years and wanted to bring that enhanced security to open source Vault.

We are happy to announce login MFA as an additional authentication factor to enhance the security of user login workflows using TOTP, Okta, Duo, and PingIdentity. Having multiple options on how MFA is used with Vault provides flexibility to support your preferred implementation. Vault Enterprise continues to support Step-up Enterprise MFA when additional factors are required for a non-login operation.

For more information on login MFA, please see the auth method documentation, the frequently asked questions, and the detailed HashiCorp Learn guide on using login MFA with PingIdentity.

»Vault as an OIDC Provider

With this release, Vault OIDC identity provider support is now generally available and has added proof key for code exchange (PKCE) support. PKCE is an extension to the authorization code flow to prevent cross-site request forgery (CSRF) and other authorization code injection attacks.

OpenID Connect (or OIDC) is an open standard that provides an identity layer on top of OAuth to verify user identity against an authorization server. The OIDC workflow typically involves a user wanting to login to a secure system. Their browser is redirected to an external OIDC identity provider, they complete login against this third-party provider, and they are routed back once they are authenticated.

For more information on Vault as an OIDC provider, please see the Vault OIDC Identity Provider documentation and detailed HashiCorp Learn guide for Vault as an OIDC Identity Provider.

»IBM Db2 Credential Management

Access to IBM Db2 is managed outside the Db2 database system. By default, user authentication is done by the operating system. Using Vault's OpenLDAP secrets engine, we can solve the challenge of credential lifecycle management for Db2 environments that are using LDAP-based authentication and support both static and dynamic credentials using the OpenLDAP secrets engine.

For more information on IBM Db2 Credential Management, please see our OpenLDAP Secrets Engine documentation and detailed HashiCorp Learn guide.

»Server Side Consistent Tokens

Tokens are the core method for authenticating and validating Vault clients, therefore nearly all requests to Vault must be accompanied by a token. Vault clients authenticate with Vault using a configured auth method. Upon successful authentication, Vault generates a token and returns it to the client.

With Vault Enterprise 1.9 and earlier, client requests sometimes got routed to a performance standby node that did not yet have replication data for the token, which resulted in an error. We introduced client features in Vault 1.7 to help manage this scenario, but this approach requires client logic through the use of HTTP headers.

With Vault 1.10, the token format has changed to enable a simpler and more reliable client experience when using performance standby nodes by having relevant minimum state information embedded within the token itself. Performance standby nodes can decide whether to forward requests to the active node if they are behind on consuming raft logs. This enables simpler clients and higher performance since standby nodes can handle many types of client requests.

The token prefix has also been updated, to make it easier for static-analysis code scanning tools to scan for Vault tokens (for example, to identify tokens accidentally stored in a version control system).

For more information on server side consistent tokens please see the detailed Frequently Asked Questions page, the HashiCorp Learn guide on Tokens and our guide on Performance Standby Nodes.

»Move Secrets Engines and Auth Methods

We have expanded support for moving secrets and auth mounts via vault secrets move and vault auth move commands from one location to another and across namespaces. There can be several reasons to migrate mounts. For example, you might need to rename mounts to align with an organizational standard. Or you might be migrating from Vault open source to Enterprise and want to divide mounts across several namespaces. These new move commands can help solve these challenges.

For more information on these new secrets and auth move methods, please see the documentation and detailed HashiCorp Learn guide.

»Other Features

There are many new features in Vault 1.10 that have been developed over the course of the 1.9.x releases. You can learn more about how to use these features in our detailed, hands-on HashiCorp Learn guides. We have summarized a few of the larger features here. Consult the changelog for full details:

• Terraform provider for Vault: Enhanced the Vault namespaced resources for easier use and added Key Management Interoperability Protocol (KMIP) support to the Terraform Vault provider. We continue to dedicate effort into building and maintaining the provider as new features are added.
• Caching for Vault Lambda Extension: Updated the Vault Lambda Extension with opt-in request caching support to avoid forwarding every HTTP request to Vault. Updated the HashiCorp Learn guide as well.
• etcd V2 API support removed: etcd V2 API has reached end of support and has been removed. Prior to upgrading to Vault 1.10, etcd storage backends should migrate to an etcd V3.
• Licenses in storage deprecation notice (Enterprise): Vault 1.10 has reached end of support for licenses in storage and customers should migrate to autoloading by Vault 1.11.
• Mount filters deprecation notice (Enterprise): Mount filters reached end of support with Vault 1.10 and customers should start using path filters instead.
• Legacy MFA deprecation notice: Legacy MFA support will be removed from Vault open source in 1.11 now that login MFA has been added.

»Upgrade Details

Vault 1.10 introduces significant new functionality. As such, please review the Upgrading Vault page, as well as the Feature Deprecation Notice and Plans page for further details.

As always, we recommend upgrading and testing new releases in an isolated environment. If you experience any issues, please report them on the Vault GitHub issue tracker or post to the Vault discussion forum. As a reminder, if you believe you have found a security issue in Vault, please responsibly disclose it by emailing security@hashicorp.com — do not use the public issue tracker. For more information, please consult our security policy and our PGP key.

For more information about Vault Enterprise, visit hashicorp.com/products/vault. You can download the open source version of Vault at vaultproject.io.

We hope you enjoy HashiCorp Vault 1.10.