We are excited to announce the public availability of HashiCorp Vault 1.1. Vault is a tool to provide secrets management, data encryption, and identity management for any infrastructure and application.
Vault 1.1 is focused on building a foundation of new infrastructure for delivering a host of advanced platform features for upcoming releases of Vault and Vault Enterprise. Major new features in Vault 1.1 include the following:
The release also includes additional new features, secure workflow enhancements, general improvements, and bug fixes. The Vault 1.1 changelog provides a full list of features, enhancements, and bug fixes.
Vault agent now supports client-side caching of leased secrets. An agent may now cache a response to a token managed client-side via auto auth. This allows for applications to work completely with Vault agent to manage a token's lifecycle, simplifying edge computing use cases or use cases where encoding logic for an application to manage token expiry with a Vault cluster may be complicated (e.g.: bootstrapping an embedded system, container management use cases, etc.)
The OpenID Connect (or OIDC) redirect auth flow is an extension to the existing JWT Auth backend that allows for users to login via a web browser to Vault.
Like the existing JWT Auth Method, the OIDC auth flow verifies claims data within a JWT token via provided cryptographic keys for via keys retrieved by OIDC Discovery. However the new OIDC redirect flow permits logins to Vault to be processed via a pre-configured OIDC Provider interface. This allows for users to login via an existing Single Sign On (SSO) service provided that SSO system exposes an OIDC Provider system.
OIDC redirect flow logins can be initiated from within the Vault UI or via the vault login command within the CLI. For more information see the documentation.
Vault can now be configured to use the transit secret engine in another Vault cluster as an auto unseal provider. For Vault users who do not have a PKCS#11-compliant HSM or external cloud-based key management service, transit auto unseal allows a second pre-configured Vault cluster to serve as an external root of trust.
For more information on Transit auto unseal, see the seals documentation.
There are many new features in Vault 1.1 that have been developed over the course of the 1.0.x releases. We have summarized a few of the larger features below, and as always consult the changelog for full details:
+character to enable wild card matching for a single directory in the path definition.
-output-curl-stringflag to print out an equivalent cURL command.
Vault 1.1 introduces significant new functionality. As such, we provide both general upgrade instructions and a Vault 1.1-specific upgrade page.
As always, we recommend upgrading and testing this release in an isolated environment. If you experience any issues, please report them on the Vault GitHub issue tracker or post to the Vault mailing list.
We hope you enjoy Vault 1.1!
The CNCF End User Technology Radar for secrets management reveals HashiCorp Vault has the broadest adoption across many companies and industries.
Learn how to use CSI to expose secrets on a volume within a Kubernetes pod and retrieve them using our beta Vault Provider for the Kubernetes Secrets Store CSI Driver.
The new Snowflake database secrets engine for Vault supports static and dynamic roles as well as root credential rotation.