HashiCorp Vault 1.10 improves Vault’s core workflows and makes key features production-ready to better serve your use cases.
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:
auto_rotate_period
configuration option.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.
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.
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.
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.
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).
Token Type | Vault 1.9.x or earlier | Vault 1.10 and later |
Service tokens | s. | hvs. |
Batch tokens | b. | hvb. |
Recovery tokens | r. | hvr. |
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.
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.
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:
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.
Learn how to use the Prometheus Operator with the new Vault Secrets Operator for Kubernetes to monitor secrets in a Grafana dashboard.
Learn how to build a secure infrastructure as code workflow with Terraform Cloud dynamic provider credentials, Microsoft Defender for Cloud, and HCP Vault.
The HashiCorp Vault partner ecosystem continues to show strong growth with the addition of more than a dozen new Vault integrations.