----
HashiCorp Vault 0.10
// Hashicorp Blog
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:
- K/V Secrets Engine v2 with Secret Versioning: Vault's Key-Value Secrets Engine now supports additional features, including secret versioning and check-and-set operations.
- Open Source Vault Web UI: The previously Enterprise-only UI has been made open source and is now released in all versions of Vault along with many enhancements.
- Root DB Credential Rotation: Root/admin credentials for databases controlled by Vault's Combined DB secrets engine can now be securely rotated with only Vault knowing the new credentials.
- Azure Auth Method: Azure Machines can now log into Vault via their Azure Active Directory credentials.
- GCP Secrets Engine: Vault can now create dynamic IAM credentials for accessing Google Cloud Platform environments.
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.
K/V Secrets Engine v2
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
createdtime 2018-03-30T22:11:48.589157362Z deletiontime 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
createdtime 2018-03-30T22:18:37.124228658Z deletiontime 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
createdtime 2018-03-30T22:18:37.124228658Z deletiontime 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
createdtime 2018-03-30T22:16:39.808909557Z deletiontime 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 -versions flag.
$ 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
createdtime 2018-03-30T22:18:37.124228658Z deletiontime 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.
Open Source Vault UI
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 DB Credential Rotation
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.
Azure Auth Method
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.
GCP Secrets Engine
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.
Other Features
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.
- Selective HMAC: Data sent to the audit log from backends within Vault can be configured to selectively HMAC values. This makes it easier for SIEMs to audit user activity across a network and application infrastructure, as well as for response teams to conduct chronological analysis of a security event.
- Security Enhancements for Return Data: Fields which contain secret data in the API no longer return this data on read, minimizing the exposure of data stored within Vault.
- New CLI and API Updates: The Vault CLI and API were updated to streamline common use cases within Vault and the configuration of Vault systems.
- gRPC support for Backend Plugins: Plugins written for Storage Backends, Auth Methods, and Secret Engines now support gRPC, allowing them to be written in languages other than Go.
- GCP Cloud Spanner Storage Backend: GCP Cloud Spanner is now a supported Storage Backend plugin.
- ChaCha20-Poy1305 Support: The Transit Secret Engine now fully supports the ChaCha20-Poly1305 cryptography scheme, allowing for encryption, decryption, convergent encryption, and key derivation.
- Replication Enhancements: Replication has been enhanced over the course of the 0.9.x timeframe. These enhancements include: the ability to encrypt the data contained in replication activation tokens as further defense in depth, changes to sys/health for DR secondaries, and enhancements to the behavior of seal-wrap with replication to wrap data stored on secondaries.
Upgrade 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 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.
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!
----
Read in my feedly
No comments:
Post a Comment