HashiCorp’s Vault 1.1 introduces significant new functionality
HashiCorp’s Vault hit 1.0 in December 2018 and even though it marked a major milestone, the latest release is no less impressive; Vault 1.1 introduces significant new functionality. This version arrives with a bunch of new features, secure workflow enhancements, general improvements, and bug fixes in tow.
HashiCorp’s Vault was born out of the company’s desire to find out how an organization has a central place to define where all their secrets live. It’s been a few months since Vault hit 1.0, which was focused on renovating Vault’s infrastructure to support high performance, scalable workloads.
Now it’s time to introduce the next version, which focuses on building a foundation of new infrastructure for delivering a host of advanced platform features for upcoming releases of Vault and Vault Enterprise, as explained in a blog post announcing Vault 1.1.
The list of major new features in Vault 1.1 includes
- 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.
This release also includes additional new features, secure workflow enhancements, general improvements, and bug fixes. If you’d like to see the full list of features, enhancements, and bug fixes, check out the Vault 1.1 changelog.
You can download the open source version of Vault here.
SEE ALSO: HashiCorp Vault hits 1.0
Vault 1.1 highlights
Secret caching via Vault Agent
Vault agent now supports client-side caching of leased secrets, which means that an agent can cache a response to a token managed client-side via auto auth. Therefore, applications can now 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. Just 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.
What’s changed in Vault 1.1 is that the new OIDC redirect flow permits logins to Vault to be processed via a pre-configured OIDC Provider interface. Therefore, users can login via an existing Single Sign On (SSO) service provided that SSO system exposes an OIDC Provider system.
You can initiate OIDC redirect flow logins from within the Vault UI or via the vault login command within the CLI. For more information, check out the documentation.
Transit auto unseal
You can now configure Vault to use the transit secret engine in another Vault cluster as an auto unseal provider. If you don’t 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.
Don’t forget to read the seals documentation if you want to learn more about Transit auto unseal.
Vault 1.1 brings a bunch of new features. The list of large(r) features also includes
- 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.
Getting started with Vault 1.1
Since this release introduces significant new functionality, you should check out not only the general upgrade instructions but also the Vault 1.1-specific upgrade page before you start using Vault 1.1.
Don’t forget to upgrade and test this release in an isolated environment. As always, if you experience any issues, you need to report them on the Vault GitHub issue tracker or post to the Vault mailing list.