HashiCorp has released version 1.13 of Vault, their secrets and identity management platform. This release includes multi-namespace access workflows, improvements to the Google Cloud secrets engine, usability improvements to MFA, and certificate revocation for cross-cluster management. HashiCorp has also released Vault as a managed service for Microsoft Azure environments.
This release introduces namespace improvements that allow for a single Vault Agent to fetch secrets across multiple namespaces. Namespaces provide isolated environments that enable tenant isolation within a single Vault instance. Previously, applications would need to authenticate per namespace with distinct Vault Agents needed per namespace.
Sharing secrets across independent namespaces is accomplished using the new group_policy_application_mode flag. Setting this flag to any will allow any authenticated and authorized Vault client to read secrets from the namespace. Setting it to within_namespace_hierarchy will revert back to allowing only Vault clients authenticated and authorized within that namespace.
The Google Cloud secrets engine has also received improvements in this release. It is now possible to generate access tokens using Google Cloud's account impersonation feature. This works around Google Cloud's ten-key limit when the same service account is used with ten or more Vault roles. Access tokens can be generated by reading from the gcp/.../token API route:
vault read gcp/roleset/my-token-roleset/token
While it is possible to generate as many of these tokens as needed, they have some limitations as compared to service account keys. They cannot be used with some client libraries and tools. They also have a static lifetime of one hour that cannot be adjusted or revoked. While service account keys are limited to ten per service account, they have a controllable lifetime.
Support for MFA was added in the 1.10 release with configurations for systems such as Duo, PingIdentity, and Okta. Rich Dubose notes that some customers indicated they had "UX challenges with these configurations". This release introduces improvements to the MFA workflow to simplify configuration and debugging. This includes using MFA name as a human-readable alias and passcode now being used consistently across methods.
Cross-cluster certificate management has also been improved. Certificate revocation lists (CRLs) and online certificate status protocol (OCSP) have been extended across multiple Vault clusters within the same PKI mount. Enabling this feature will provide an eventually consistent, globally unified CRL. Revocation entries will be written to the local cluster that issued the certificate but also to the primary replication cluster. Enabling asynchronous cross-cluster revocation will allow certificates to be revoked from clusters other than the issuing cluster.
HashiCorp has also announced that Vault is generally available as a managed service for Microsoft Azure environments on the HashiCorp Cloud Platform (HCP). This is in addition to previously released support for workloads running within AWS. Within Azure, workloads running on Azure Virtual Machines or Azure Kubernetes Service (AKS) are supported.
More details on these and other changes included in this release can be found in the release post. 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.