Vault 1.8 offers a new Vault Diagnose command, Key Management secrets engine AWS GA support, updates to Integrated Storage Autopilot, and more.
We are pleased to announce the general availability of HashiCorp Vault 1.8. Vault provides secrets management, data encryption, and identity management for any application on any infrastructure.
Vault 1.8 focuses on improving Vault’s core workflows and making key features production-ready to better serve your use cases. In this release, we added a new Vault Diagnose command, made improvements to the Integrated Storage Autopilot feature, released Amazon Web Services (AWS) GA support for the Key Management secrets engine, and made many other improvements across the project.
This release includes the following key features and improvements:
vault operator diagnosecommand to enable faster troubleshooting and user-friendly diagnostics in situations when Vault is not starting.
Troubleshooting is a fundamental task for Vault operators. However, root causing an error with Vault can be a complex task since Vault connects to so many other systems; it can be difficult to ascertain what is wrong in a timely and efficient manner.
In Vault 1.8 we are introducing Vault Diagnose:
vault operator diagnose is a new operator-centric command focused on providing a clear description of what is working in Vault, and what is not working. The command focuses on why Vault cannot serve requests, but will also warn on configurations or statuses that it deems to be unsafe in some way. To see a demo of Vault diagnose in action please watch this video:
The operator diagnose command should be used primarily when Vault is down or failing to boot correctly. The command can be used safely regardless of the state Vault is in.
Vault 1.7 introduced Integrated Storage Autopilot, which allows automatic, operator-friendly management of the integrated storage servers (similar to Consul’s Autopilot subsystem). Autopilot can monitor cluster node health, prevent disruption to the Raft quorum due to an unstable new node, and periodically check and automatically clean up failed servers.
In Vault 1.8, we added support for disaster recovery secondary clusters to have their own Autopilot configuration, managed independently of their primary, which allows for greater control of how the clusters are managed. For more information on either of these Integrated Storage enhancements, please see our documentation and detailed Learn Guide.
Many cloud providers offer a Key Management Service (KMS), where encryption keys can be issued and stored for maintaining a root of trust. The Key Management secrets engine provides an API abstraction layer and offers a standardized workflow for distribution and lifecycle management of cryptographic keys in various KMS providers. It allows organizations to greatly simplify the lifecycle management of keys Vault has distributed and maintains centralized control of those keys in Vault, while still taking advantage of cryptographic capabilities native to the KMS providers.
In addition to supporting Microsoft Azure Key Vault, we are happy to announce that the Key Management secrets engine is now also ready for production use with AWS KMS. This feature lets you use Vault to manage keys in AWS KMS for automating many lifecycle operations, such as creation, reading, updating, and rotating keys. This greatly simplifies the process of bringing your own keys to a cloud provider and managing the lifecycle of those keys.
Vault Enterprise includes a number of features that go beyond what is supported in the open source version, such as replication for DR and HA, HSM auto unseal support, performance standby nodes, etc. To use these features an Enterprise license needs to be applied to a Vault cluster.
Prior to Vault 1.8, Vault Enterprise features could be unlocked using special binaries that contained embedded licenses, or via a license written into Vault storage using the PUT
sys/license API. Starting in Vault 1.8, those options still exist but will be deprecated in a future release, and the recommended mechanism for managing licenses is called License Autoloading. As much as possible, we tried to maintain a seamless experience for existing clusters that are upgraded to 1.8, but new clusters must use autoloading. New users of 1.8 Enterprise will also notice we have added an end-user license agreement (EULA) check to ensure agreement to a EULA.
There are many new features in Vault 1.8 that have been developed over the course of the 1.7.x releases. You can learn more about how to use many of these features in detailed, hands-on Learn Guides through the HashiCorp Learn site. We have summarized a few of the larger features below, and you can consult the changelog for full details:
Vault 1.8 introduces significant new functionality. As such, please review the general upgrade instructions page for details.
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 discussion forum. As a reminder, if you believe you have found a security issue in Vault, please responsibly disclose by emailing firstname.lastname@example.org and do not use the public issue tracker. Our security policy and our PGP key can be found here.
We hope you enjoy Vault 1.8.
The HashiCorp Vault ecosystem continues to grow with the addition of 25 new integrations this past quarter.
Here’s how to use HashiCorp Boundary to provide identity-based remote access and credential management for Kubernetes clusters.
Before we ring in the new year, here’s a look back at some of the most important moments in 2022 for HashiCorp.