Vault 1.13 adds Kubernetes Operator, MFA improvements, and more

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:

• Multi-namespace access workflows
• Azure auth method
• Google Cloud secrets engine
• KMIP secrets engine
• MFA login
• Vault Agent
• Certificate revocation for cross-cluster management

Additional new features include:

• Event-based notifications (alpha)
• Vault Operator (beta)
• HCP link for self-managed Vault (private beta)
• PKI health checks
• Managed Transit keys

»Multi-namespace access improvements

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.

»Microsoft Azure auth improvements

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.

»Google Cloud secrets engine improvements

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.

»Event-based notifications (alpha)

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.

»Undo logs

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.

»MFA login improvements

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.

»Vault Secrets Operator (beta)

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 Agent improvements

Vault 1.13 includes several enhancements to the Vault Agent.

• Users can get started with Vault Agent without needing to set up auth methods. This feature is for learning and testing. It is not recommended for production use.
• Listeners for the Vault Agent can now be configured with a role of “metrics only” so that a service can be configured to listen on a particular port for the purpose of metrics collection only.
• The Vault Agent can now read configurations from multiple files.
• The Vault Agent persists logging when there is a mismatch between the agent and server.

»HCP link for self-managed Vault (private beta)

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 siranjeevi.dheenadhayalan@hashicorp.com.

»Certificate revocation for cross-cluster management

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.

»PKI health checks

Vault 1.13 introduces PKI health check CLI commands to help organizations troubleshoot issues and avoid downtime. The following configurations are included:

• CA
• CRL validity
• Role permissions
• Audit for potentially unsafe parameters
• API’s
• Certificate volume

»Enhanced KMIP with PKCS#11 operations

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.

»Managed Transit keys

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.

»Enable rotate-root in Azure auth method

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.

»Upgrade details

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.

Vault 1.13 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.