HashiCorp Vault 1.13 brings enhancements to team workflows, integrations, and visibility.
HashiCorp is pleased to announce the general availability of Vault 1.13. Vault provides secrets management, data encryption, and identity management for any application on any infrastructure.
Vault 1.13 focuses on Vault’s core secrets workflows as well as team workflows, integrations, and visibility. The key features in this release include improvements to:
Additional new features include:
When customers have secrets distributed across multiple (independent) namespaces, their applications need to authenticate multiple times to Vault, creating an unnecessary burden. Additionally, customers using Vault Agent need to run separate Vault Agent instances to talk to each namespace. Vault 1.13 includes namespace improvements to alleviate these challenges by enabling a single agent instance to be able to fetch secrets across multiple namespaces.
Prior to Vault 1.13, only Microsoft Azure virtual machines could leverage the Azure auth method to authenticate to Vault. Vault 1.13 introduces the ability to authenticate to Azure Functions and the Azure App Service.
To avoid exhausting Google Cloud’s 10-key limit when the same service account is used with 10 or more Vault roles, Vault 1.13 improves the Google Cloud secrets engine integration by using its own service account with Google Cloud’s account impersonation feature to generate access tokens.
Vault 1.13 introduces an alpha release of a lightweight event-based notification feature that can be used to notify downstream applications of changes to Vault secrets. Applications and external entities can subscribe to events via a websockets API.
We identified a race condition associated with Vault’s replication that is triggered when frequent updates to a set of keys can occasionally result in a merkle diff or sync loop. This condition was corrected in Vault 1.12. However, it was disabled in 1.12. Vault 1.13 includes this correction as enabled by default.
As of 1.10, Vault introduced Login MFA, a standardized configuration for integration with Duo, PingIdentity, Okta, and TOTP, but some customers have found UX challenges with these configurations. With these improvements introduced in 1.13, Customers will be able to migrate to Login MFA more easily. Login MFA will be easier to configure and debug.
Prior to 1.13, customers had to specify an MFA ID for each MFA provider, which is a long UUID. This can be cumbersome for customers with many clusters. 1.13 introduces MFA name as a human-readable alias.
Passcode was not being used consistently across methods, now there is consistent behavior across the CLI and API, regardless of method.
Kubernetes applications using Vault for secrets management have had the option of leveraging a sidecar or the CSI secrets store provider to inject secrets into files. This created a number of challenges.
First, these approaches required applications to be modified if you wanted the ability to read from a file. Furthermore, applications need to be aware of when credentials have been modified so that they can be re-read from the file.
Vault 1.13 introduces the Vault Operator to provide a resolution to these challenges. The Operator will allow customers to natively sync secrets from Vault to Kubernetes clusters.
The Vault Secrets Operator will not be immediately available with the GA launch of 1.13. It will be available in late March.
Vault 1.13 includes several enhancements to the Vault Agent.
In Vault 1.13 and the HashiCorp Cloud Platform (HCP), we’ve introduced a feature enabling active connections between self-managed Vault clusters and HCP. The feature is similar to the Consul global management plane. You sign up for free on HCP to use it, and you can connect self-managed clusters into one platform and access applications built on top of HCP, such as the operations monitoring and usage insights features currently in private beta.
We’ve chosen specifically to add these capabilities to HCP because adding data processing functionalities to the Vault binary could increase memory consumption. To participate in this private beta you must first upgrade to Vault 1.13. However, the upgrade doesn’t need to occur in your production environments. Simply upgrade a pre-production environment to Vault 1.13 and you can start testing. If you would like to participate in the beta please contact our product team by emailing email@example.com.
To improve the cross-cluster certificate management user experience, Vault 1.13 extends revocation capability support (including certificate revocation lists (CRLs) and online certificate status protocol (OCSP)) across multiple Vault clusters for the same PKI mount.
Vault 1.13 introduces PKI health check CLI commands to help organizations troubleshoot issues and avoid downtime. The following configurations are included:
In Vault 1.13 we have added support in the KMIP secrets engine (KMIP Asymmetric Key Lifecycle, Advanced CryptoGraphic Server profiles) for key PKCS#11 operations such as signature (sign/verify), random number generation (RNG), and MAC sign/verify. These should enable better KMIP/PKCS#11 integrations for Vault with a broader base of devices and software.
Customers with particularly conservative risk profiles require their keys to be created and stored within hardware security modules (HSMs) or an external KMS. We want to make it easier for organizations to leverage Vault across all sections of their infrastructure, including HSMs and KMS.
Vault 1.13 introduces support for offloading Transit key cryptographic operations (encrypt, decrypt, MAC sign/verify, RNG generation) from Transit to an HSM or cloud KMS. Organizations can now generate new Transit keys and key pairs using key material in an external HSM or KMS, and then use them for encryption and signatures on secrets in Vault. These features make it possible to centralize secrets and encryption management in Vault even in cases where Vault doesn’t support certain cryptographic algorithms (such as SEED/ARIA) required by an organization’s compliance policies.
While the rotate-root endpoint is available in the Azure secrets engine, it has not been implemented in our Azure auth method. For customers who want to rotate their client secrets in the Azure auth method mounts on a routine basis, this requires manual rotation. To do this, users need to manually rotate the client secret in Azure, and then manually update the Azure auth configuration. At scale, this is impractical.
Vault 1.13 adds rotate-root capabilities to the Azure auth method, allowing users to generate a new client secret for the root account defined in the config of Azure auth method mounts. The generated value will be known only by Vault.
This release also includes additional new features, workflow enhancements, general improvements, and bug fixes. The Vault 1.13 changelog lists all the updates. Please visit the Vault Release Highlights page for step-by-step tutorials demonstrating the new features.
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 firstname.lastname@example.org — 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.
Learn about the ACME protocol for PKI, the common problems it solves, and why it should be part of your certificate management roadmap.
New HashiCorp Vault ecosystem integrations extend security use cases for customers.
With Vault and Boundary, HashiCorp makes its debut in Gartner’s Magic Quadrant for privileged access management.