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:
- Secret Caching with Vault Agent: Securely cache secrets for easy access to applications and edge services.
- OIDC Auth Flow: Update to the JWT Auth Method to allow users to authenticate to Vault via OpenID Connect.
- Transit Auto-Unseal: Auto-Unseal a Vault cluster from a separate Vault cluster via transit encryption.
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.
» Secret Caching via Vault Agent
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.)
» OIDC Auth Flow
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.
» Transit Auto Unseal
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.
» Other Features
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:
- InfluxDB Database Plugin: Use Vault to dynamically create and manage InfluxDB users
- Group and Policy UI Search: Search for Group and Policy IDs when creating Groups and Entities instead of typing them in manually.
- Permissions-based UI Wizards: The Vault UI's navigation and onboarding wizard now only displays items that are permitted in a users' policy.
- ACL Path Wildcard: ACL paths can now use the
+character to enable wild card matching for a single directory in the path definition.
- cURL Command Output: CLI commands can now use the
-output-curl-stringflag to print out an equivalent cURL command.
- Response Headers From Plugins: Plugins can now send back headers that will be included in the response to a client. The set of allowed headers can be managed by the operator.
» Upgrade Details
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!