We are excited to announce the public availability of HashiCorp Vault 1.3. Vault is a tool to provide secrets management, data encryption, and identity management for any infrastructure and application.
Vault 1.3 is focused on improving Vault's ability to serve as a platform for credential management workloads for services such as Active Directory and Kubernetes and support global multi-cloud operations with high performance, compliance-regulated workloads.
This release includes the following features:
This release also includes additional new features, secure workflow enhancements, general improvements, and bug fixes. The Vault 1.3 changelog provides a full list of features, enhancements, and bug fixes.
Note: This is a Vault Enterprise feature
Vault Enterprise 1.3 sees the introduction of entropy augmentation: a feature that allows Vault to sample entropy (or randomness for cryptographic operations) from an external source via the seals
interface.
Entropy, or statistical randomness, is critical in cryptography and important for protecting secrets within Vault. While the system entropy used by Vault (which varies depending on where Vault is being run) is more than capable of operating in most threat models, there are some situations where additional entropy from hardware-based random number generators is desirable.
Entropy augmentation allows Vault Enterprise to supplement its system entropy with entropy from an external cryptography module. Designed to operate in environments where alignment with cryptographic regulations like NIST SP800-90B is required or when augmented entropy from external sources such as hardware true random number generators (TRNGs) or quantum computing TRNGs are desirable, augmented entropy replaces system entropy when performing random number operations on critical security parameters (CSPs).
These CSPs have been selected from our previous work in evaluating Vault for conformance with FIPS 140-2 guidelines for key storage and key transport and include the following:
For more information on entropy augmentation, see our learn guide and the system documentation.
Vault 1.3 sees a number of improvements to Vault’s integrated storage (also known as the Raft Storage Backend) and the transition of integrated storage to Beta.
This release includes the following new features:
Non-Voter Nodes: Storage nodes dedicated to streamlining performance.
Recovery Mode: Similar to Consul’s recovery mode, a secure emergency mode to directly manage Vault's storage.
UI Improvements: New UI to better manage integrated storage and to download/manage snapshots.
Improvements to integrated storage's backend systems to improve performance and stability.
Integrated storage is in the Beta phase, and as such we do not recommend or support using integrated storage for production workloads. We continue to work with the community on resolving bug fixes and testing, and plan on creating a reference architecture and fully supporting integrated storage as a storage backend for production systems in an upcoming Vault release.
For more information on integrated storage, see our learn guide and the system documentation.
Starting in Vault 1.1, we began an evolution of features to improve privileged access management for static credential systems. Vault 1.3 continues this focus by adding new functionality to support Check In / Check Out management of Active Directory credentials.
Check In / Check Out is a new feature that allows Vault users to manage a set of AD credentials available within a system. This selection of AD Credentials can be shared within a team such that each team member can only be allowed to use one selected credential at a time, with credentials rotated as a user checked their credential back in.
For more information on AD Check In / Check Out, see our learn guide and the system documentation.
A constant goal of the Vault team is to improve the experience of deploying, configuring, and managing Vault. Vault 1.3 introduces new functionality towards this goal with the release of a new CLI command, vault debug
.
Debug is a command that gathers metrics about a node’s health - including replication status, information about the host such as available memory, configuration state of the server, etc. Once gathered, this data is outputted to a tarball archive. These health metrics can then be shared with groups like HashiCorp Customer Success to support investigations in root cause analysis for issues.
Some of the data that vault debug
accesses may be very sensitive. As such, Vault only gathers debug data from endpoints Vault users have access to via their ACL policies. If the user attempting to use vault debug
does not have permission to access a certain endpoint for a particular target, its output will be omitted and a permissions error will be logged within the Audit Log.
The archive generated from vault debug
outputted should be treated with care. Vault does not natively encrypt this archive, and we recommend users transmit this archive over encrypted channels when opting to share it.
For more information on vault debug
see the documentation.
Note: This is a Vault Enterprise feature
In Vault 0.8 we introduced Mount Filters, a feature that allows for Vault Enterprise admins to select mounts (and thus secrets) that will not be forwarded in replication. Mount Filters has been successful in supporting enterprise governance and compliance workloads, in particular supporting compliance requirements such as GDPR that restrict the geographical movement of certain secrets.
With the introduction of namespaces in Vault 0.11, Vault Enterprise introduced a new way to segment secrets that does not map well with Mount Filters’ ability to manage the distribution of data across replicated clusters.
In Vault 1.3 we are releasing new functionality that enables Vault users to specify path filters. These path filters allow for mounts within namespaces to be filtered similar to existing mount filters, allowing for namespace admins to specify what secrets within a namespace will be omitted from performance replication.
For more information on path filters, see the documentation.
Vault 1.3 sees the release of several new endpoints to support Oracle Cloud workloads. These features, developed as a contribution from the Oracle Cloud engineering team, include the following:
For more information see Oracle’s announcement blog.
There are many new features in Vault 1.3 that have been developed over the course of the 1.2.x releases. We have summarized a few of the larger features below, and as always consult the changelog for full details:
Vault 1.3 introduces significant new functionality. As such, we provide both general upgrade instructions and a Vault 1.3-specific upgrade page.
As always, we recommend upgrading and testing this release in an isolated environment. If you experience any issues, please report them on the Vault GitHub issue tracker or post to the Vault mailing list.
For more information about HashiCorp Vault Enterprise, visit https://www.hashicorp.com/products/vault. Users can download the open source version of Vault at https://www.vaultproject.io.
We hope you enjoy Vault 1.3!
A recap of HashiCorp infrastructure and security news and developments on AWS from the past year, from self-service provisioning to fighting secrets sprawl and more.
If you’re attending AWS re:Invent in Las Vegas, Nov. 27 - Dec. 1, visit us for breakout sessions, expert talks, and product demos to learn how to accelerate your adoption of a cloud operating model.
10 new HashiCorp Vault ecosystem integrations extend security use cases for customers.