HashiCorp has released Vault 1.10, introducing a number of new features to their secrets and identity management platform. Server-side consistent tokens provide greater control over the eventual consistency model when using performance standby nodes. Authentication can now be performed using the new open source login multi-factor authentication integration. Additional features include multiplexing support for database plugins and improved telemetry for Vault agent.
In a typical Vault high availability structure, one Vault server will be active in the cluster and handle all requests. With Vault Enterprise 0.11 or later, it is possible to have the standby nodes act as performance standby nodes and handle most read-only requests. This provides additional horizontal scalability of read requests within a single Vault cluster.
In some sequences of operations, the combination of performance standbys with integrated storage meant that read-after-write consistency wasn't present. While some improvements were made in Vault 1.7 to address this, they weren't applicable in all use cases. Vault 1.10 adds Server Side Consistent Tokens to address this issue.
This feature ensures that tokens returned from token create requests have the relevant minimum write-ahead logs (WAL) state information included with the token itself. With this information, performance standby nodes can decide whether to forward the requests on to active nodes. According to Justin Weissig, senior technical product marketing manager with HashiCorp, this "enables simpler clients and higher performance since standby nodes can handle many types of client requests."
In addition to the consistency improvements, the release adjusts the token prefixes to make them easier for static analysis tools to scan for. This simplifies creating automation to identify tokens that may have accidentally been committed into source code.
This release sees the previous enterprise-only feature of multi-factor authentication move into the open-sourced version of Vault. At the time of release, MFA in Vault supports Time-based One-time Password (TOTP), Okta, Duo, and PingID. There are two ways to validate a 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" \
http://127.0.0.1:8200/v1/auth/userpass/login/alice
In the more conventional two-phase login method, the X-Vault-MFA header is not provided in the request. In this approach, after sending a login request, the user receives an auth response detailing the MFA requirements. These requirements include which MFA types should be used to validate the response, their method IDs, and a Boolean value indicating whether the MFA method uses passcodes.
Vault OIDC identity provider support is now moved into general availability. In addition, support for proof key for code exchange (PKCE) has been added. PKCE is used to help prevent authorization code injection attacks such as cross-site request forgery (CSRF)and .
Additional improvements include added runtime metrics for Vault Agent for authentication, cache, and proxy counters; support for database plugin multiplexing, and support for the PKI secrets engine to offload key generation and certificate signing to an HSM. Supported HSM include PKCS#11 HSMs, Azure Key Vault, and AWS KMS.
More details on these and other changes included in this release can be found in the release post and changelog. An upgrade guide is available to assist in the process of upgrading existing clusters. Vault can be found either as open-source or in an enterprise edition.