HashiCorp has released version 1.0 of Vault, their secrets management tool that open-sources the auto-unseal feature needed to continue using Vault server after a failure or a restart. In this version, a new type of token called batch is now available for ephemeral workloads. Another new feature is that service account tokens are now supported in Kubernetes auth via projected volumes to inject tokens into a pod. HashiCorp also launched a support utility called Vault Advisor to help users to automatically remove unnecessary access to certain credentials when using Vault.
Open sourcing the auto-unseal feature, previously available only in the enterprise version, was a highly request featured, namely by Kubernetes guru Kelsey Hightower. Auto-unseal is the process of making data decryption possible after a failure or restart in the cluster happens. When Vault first boots, it is sealed and all data stored is encrypted. To decrypt data, you need to unseal it first.
The auto-unseal process can also be integrated with a cloud provider’s key management service, which allows an engineer to delegate the unsealing process and ease operations in the event of partial failure. For example, in AWS KMS the master key will be reconstructed to unseal the cluster using the previously stored key. All major cloud providers are supported: AWS, Azure, GCP, and Alibaba. For example, there's a guide with Terraform and AWS KMS.
A few projects in GitHub like vault-init, vault-unsealer, and vault-unseal already replicate the auto-unseal feature for those that didn't have the Enterprise version of Vault. But now these projects are no longer needed because the official feature that has been used for enterprise customers is available for the general community.
Another important new feature in Vault 1.0 is that there's a new type of token called batch tokens, and what used to be known as simply tokens now are called service tokens. Service tokens support all token features like renewal or revocation and are stored in the Vault cluster for tracking purposes. Batch tokens don't require storage on disk, therefore, they become a good candidate for short-lived and bursty workloads, like serverless applications.
Vault 1.0 also includes better integration with Kubernetes. Applications that are running in the pods will be able to use Vault to manage secrets, cryptographic operations, and dynamic access. For example, you can create a pod that requests a set of temporary database credentials dynamically by using dynamic secrets.
HashiCorp also launched a support utility called Vault Advisor which will educate users on how to use Vault properly, reporting if Vault is correctly configured and if applications are using it appropriately. By reading Vault's logs, the advisor utility can discover opportunities to improve Vault usage. For example, verifying that users have the minimum set of permissions required to use their Vault keys.
According to HashiCorp CTO Armon Dadgar, 1.0 means that the primary use cases are understood, stable, and deployed broadly over many enterprises such as Adobe, Hulu, Splunk, Equinix, and others.
HashiCorp Vault 1.0 is available to download through HashiCorp's website.
