HashiCorp has released Vault 1.10, introducing a number of new features to its secret and identity management platform. Consistent server-side tokens provide greater control over any consistency model when using performance nodes. Authentication can now be done through the new open source login multifactor authentication integration. Additional features include multiplexing support for database connectors and enhanced telemetry for the Vault Agent.
In a typical Vault high availability structure, a Vault server will be active on the cluster and handle all requests. With Vault Enterprise 0.11 or later, standby nodes may act as performance standby nodes and handle most read-only requests. This provides additional horizontal scalability of read requests within a single Vault cluster.
Vault high availability structure consisting of active and standby nodes (credit: HashiCorp)
In some sequences of operations, the combination of performance standby with built-in storage meant that there was no read-write consistency. Although some improvements were made to Vault 1.7 to fix this, they were not applicable to all use cases. Vault 1.10 adds consistent server-side testimonials to fix this issue.
This feature ensures that returned testimonials from token creation requests have the relevant minimum advance record (WAL) status information included with the token itself. With this information, performance nodes can decide whether to forward requests to active nodes. According to Justin Weissig, senior technical director of product marketing at HashiCorp, this “enables simpler customers and higher performance, as waiting nodes can handle many types of customer requests.”
In addition to consistency enhancements, the version adjusts token prefixes to make it easier for them to explore static analysis tools. This simplifies the creation of automation to identify files that may have been accidentally sent to the source code.
In this version, the above feature only for multifactor authentication companies is moved to the open source version of Vault. At launch, MFA in Vault supports the unique time-based password (TOTP), Okta, Duo, and PingID. There are two ways to validate an MFA login request: single-phase login and two-phase login.
In a single-phase login, the required MFA information is embedded in the login request using the X-Vault-MFA header:
$ curl \ –header “X-Vault-Token: …” \ –header “X-Vault-MFA: d16fd3c2-50de-0b9b-eed3-0301dadeca10: 695452” \
In the more conventional two-phase login method, the X-Vault-MFA header is not provided in the application. In this approach, after submitting a login request, the user receives an authentication response detailing the MFA requirements. These requirements include what types of MFAs should be used to validate the response, their method IDs, and a Boolean value indicating whether the MFA method uses passwords.
Vault OIDC Identity Provider support is now moving to general availability. In addition, support has been added for the code exchange test key (PKCE). PKCE is used to help prevent authorization code injection attacks, such as cross-site application forgery (CSRF) and.
Additional enhancements include added runtime metrics for Vault Agent for authentication, cache, and proxy counters; support for database connector multiplexing and support for the PKI secret engine for downloading key generation and certificate signing to an HSM. Supported HSMs include HSM PKCS # 11, Azure Key Vault, and AWS KMS.
You can find more details about these and other changes included in this release in the release and change log. An upgrade guide is available to assist in the process of upgrading existing clusters. Vault can be found as open source or in a business edition.