HashiCorp has released Vault 1.10, introducing a number of new features to their secret and identity management platform. Consistent server-side tokens provide more control over a possible consistency model when using nodes in readiness for performance. Authentication can now be done using the new open source multi-factor authentication integration. Additional features include multiplexing support for database plugins and enhanced telemetry for the Vault agent.
In a typical Vault high availability structure, one Vault server will be active in the cluster and process all requests. With Vault Enterprise 0.11 or later, backup nodes can act as performance-ready nodes and process most read-only requests. This provides additional horizontal scalability of read requests within a single Vault cluster.
High vault availability structure consisting of active and backup nodes (credit: HashiCorp)
In some sequences of operations, the combination of standby mode with integrated storage meant that there was no read-write sequence after writing. Although some improvements have been made in Vault 1.7 to address this, they have not been applicable in all use cases. Vault 1.10 adds serial tokens from the server to address this issue.
This feature ensures that tokens returned from token creation requests have the appropriate Minimum Log Status (WAL) status information included in the token itself. With this information, performance-ready nodes can decide whether to forward requests to active nodes. According to Justin Weissig, senior technical product marketing manager at HashiCorp, “this allows for simpler customers and higher performance because backup nodes can handle many types of customer requests.”
In addition to sequence improvements, the release adjusts token prefixes to make them easier to scan from static analysis tools. This simplifies the creation of automation to identify tokens that may have been accidentally introduced into the source code.
This version sees that the previous feature only for multi-factor authentication is moved to the open source version of Vault. At the time of launch, MFA in Vault supports time-based one-time password (TOTP), Okta, Duo and PingID. There are two ways to validate an MFA entry request: single-phase entry and two-phase entry.
For single-phase logins, 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 entry method, the X-Vault-MFA header is not provided in the application. In this approach, after sending an application for entry, the user receives a verification response with details of the MFA requirements. These requirements include which types of MFAs should be used to validate the response, their method identifiers, and a Boolean value indicating whether the MFA method uses passwords.
Vault OIDC identity provider support has now been moved to general availability. In addition, code exchange verification key (PKCE) support has been added. The PKCE is used to prevent attacks by injecting an authorization code, such as forging cross – site requests (CSRF) and.
Additional enhancements include added runtime metrics for the Vault Agent authentication, cache, and proxy counters; support for multiplexing database plug-ins and support for the PKI secret secretion mechanism for unloading key generation and signing a certificate to HSM. Supported HSMs include PKCS # 11 HSM, Azure Key Vault and AWS KMS.
More details on these and other changes included in this version can be found in the publication’s publication and in the change register. An upgrade guide is available to assist in the process of upgrading existing clusters. Vault can be found either as an open source or in a corporate edition.
Add Comment