We are excited to announce the release of HashiCorp Vault 0.10. Vault is an identity-based security product that provides secrets management, encryption as a service, and identity and access management, leveraging any trusted source of identity to enforce access to systems, secrets, and applications.
The 0.10 release of Vault delivers new features to help with automating secrets management and enhancing Vault's ability to operate natively in multi-cloud environments. In addition to this new functionality Vault 0.10 will open source the Web UI.
New features in 0.10 include:
The release also includes additional new features, secure workflow enhancements, general improvements, and bug fixes. The Vault 0.10 changelog provides a full list of features, enhancements, and bug fixes.
As always, we send a big thank-you to our community for their ideas, bug reports, and pull requests.
In Vault 0.10 is a revamped Key/Value Secrets Engine that allows for secrets to be versioned and to be updated with check-and-set operations. Multiple versions of a single value can be read and written within Vault.
These features are available via the API as well as the new vault kv subcommand within the CLI. Because the API is different between versions 1 and 2 of the K/V Secrets Engine, for backwards compatibility, in 0.10 new K/V mounts created within Vault will not support versions unless explicitly enabled. Existing K/V mounts can be upgraded to enable versioning, however support for downgrading K/V mounts to a non-versioned K/V is not supported. The new vault kv subcommand transparently handles the changes in API to make it easy to use both versions of the secrets engine.
To mount a new, versioned instance of the K/V Secrets engine, issue the following CLI command:
$ vault secrets enable kv-v2
Existing non-versioned K/V instances can be upgraded from the CLI with enable-versioning:
$ vault kv enable-versioning secret/ Success! Tuned the secrets engine at: secret/
Writing data to a versioned K/V mount via the vault kv subcommand is similar to writing secrets via vault write:
$ vault kv put secret/my-secret my-value=shh Key Value --- ----- created_time 2018-03-30T22:11:48.589157362Z deletion_time n/a destroyed false version 1
The new versioned K/V mounts (and the
vault kv subcommand) support writing multiple versions. This can be performed with the optional Check and Set (or
-cas flag). If
-cas=0 the write will only be performed if the key doesn’t exist. If the index is non-zero the write will only be allowed if the key’s current version matches the version specified in the cas parameter.
$ vault kv put -cas=1 secret/my-secret my-value=itsasecret Key Value --- ----- created_time 2018-03-30T22:18:37.124228658Z deletion_time n/a destroyed false version 2
When now reading the secret via kv get, the current version is shown:
$ vault kv get secret/my-secret ====== Metadata ====== Key Value --- ----- created_time 2018-03-30T22:18:37.124228658Z deletion_time n/a destroyed false version 2 ====== Data ====== Key Value --- ----- my-value itsasecret
However previous versions of the secret are still accessible via the -version flag:
$ vault kv get -version=1 secret/my-secret ====== Metadata ====== Key Value --- ----- created_time 2018-03-30T22:16:39.808909557Z deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- my-value shh
There are two ways to delete versioned data with vault kv: vault kv delete and vault kv destroy.
vault kv delete performs a soft deletion that marks a version as deleted and creates a
deletion_time timestamp. Data removed with
vault kv delete can be un-deleted by using
vault kv undelete
For example, the latest version of a secret can be soft-deleted by simply running
vault kv delete. A specific version can be deleted using the
$ vault kv delete secret/my-secret Success! Data deleted (if it existed) at: secret/my-secret
A version soft-deleted using
vault kv delete can be restored with
vault kv undelete
$ vault kv undelete -versions=2 secret/my-secret Success! Data written to: secret/undelete/my-secret $ vault kv get secret/my-secret ====== Metadata ====== Key Value --- ----- created_time 2018-03-30T22:18:37.124228658Z deletion_time n/a destroyed false version 2 ====== Data ====== Key Value --- ----- my-value itsasecret
However, data removed by vault kv destroy cannot be restored.
$ vault kv destroy -versions=2 secret/my-secret Success! Data written to: secret/destroy/my-secret
The new K/V Secrets Engine supports a number of additional features including metadata and new ACL policy rules. For more information in the K/V Secrets Engine see the documentation.
With Vault 0.10 we have worked to open source the UI. Now all versions of Vault contain the UI, which enables core secrets management, encryption as a service, and identity & access management to be done natively within Vault's UI, as well as core system configuration tasks for managing the deployment of a Vault environment.
The UI has also been updated to include new extensions for managing Auth Methods and policies, allowing users who are more comfortable configuring Vault within a GUI to be able to manage RBAC for secrets and the configuration of their system.
For more, see the Introduction to Vault OSS UI tutorial.
Root/admin credentials for databases that are configured via the Combined DB Secrets Engine now support rotation. This functionality allows for credentials given to Vault to immediately be rotated upon Vault's configuration with a system, ensuring that Vault is the only system of record for configured databases' admin or root credentials. These can also be rotated on-demand at any time.
Root Credential Rotation is designed to minimize "secret sprawl" of admin credentials, minimizing the probability of this very sensitive data being used to gain undue access to a database. When combined with automation and scripting, credential rotation is intended to allow Vault to operate in highly secure environments where bootstrapping is automated and systems other than Vault maybe exposed to root credentials.
Root Credential Rotation is complementary with Dynamic Secrets. Dynamic Secrets enable Vault to create ephemeral credentials for clients on demand, but Vault itself needs a long lived credential for persistent access to the underlying system. Automating the rotation of this persistent connection improves the overall security posture of Vault.
Vault 0.10 now supports integration with Azure Active Directory (or AAD) to allow Vault to authenticate Vault users with AAD machine credentials.
The Azure Auth Method is intended to allow applications hosted natively within Azure to streamline their authentication with Vault, simplifying the workflow for logging into a Vault environment and accessing data that is authorized to that application.
While the Vault 0.10 release focuses on Azure machine credentials, we are actively working with Microsoft to support other Azure Active Directory credential types for future versions of Vault.
For more information on the Azure Active Directory Auth Method, see Azure's blog Scaling Secrets in Azure: HashiCorp Vault speaks Azure Active Directory.
The Vault team has been collaborating with Google on the development of secrets engines and auth methods to integrate with Google Cloud Platform. Vault 0.10 sees the continuation of our partnership with the release of the GCP Secrets Engine which allows Vault users to create dynamic GCP credentials for accessing Google Cloud Platform infrastructures. This allows short lived credentials to be given to applications that need to access GCP using the Dynamic Secrets pattern.
For more information on the GCP Secrets Engine, see Google's blog How to dynamically generate GCP IAM credentials with a new HashiCorp Vault secrets engine.
There are many new features in Vault 0.10 that have been developed over the course of the 0.9.x releases. We have summarized a few of the larger features below, and as always consult the Changelog for full details.
Vault 0.10 introduces significant new functionality. As such, we provide both general upgrade instructions and a Vault 0.10-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 a free, 30-day trial of Vault Enterprise, visit https://www.hashicorp.com/products/vault/trial?utm_source=vault010blog.
We hope you enjoy Vault 0.10!
New Sentinel HTTP import capabilities in Vault Enterprise 1.5 enable new sophisticated governance policies. See it in action.
Try HashiCorp Vault as a managed cloud service by signing up for the HCP Vault private beta.
Developers no longer have to make their Lambda functions Vault-aware.