HashiCorp Vault 0.8

We are proud to announce the release of HashiCorp Vault 0.8. Vault is an infrastructure automation security product that provides secrets management, encryption as a service, and privileged access management.

The 0.8 release of Vault is focused on bringing major, new functionality to Vault. Highlights include:

• Secure Plugins
• Disaster Recovery (Vault Enterprise)
• Mount Filters for Replication (Vault Enterprise)
• Entities and Multi-Factor Authentication (Vault Enterprise)

The release also includes additional new features, secure workflow enhancements, general improvements, and bug fixes. The Vault 0.8 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.

»Secure Plugins

Vault 0.8 introduces the ability to securely author and use plugins within Vault Enterprise and Vault Open Source to support custom integrations for Authentication and Secrets backends. These can either be developed by the user themselves or shared and integrated from other developers.

In Vault (as well as in other HashiCorp projects like Terraform), a custom plugin consists of a Go application that launches external processes.

The plugin then interfaces and communicates back to Vault via GRPC over a mutually-authenticated channel encrypted with a one-time use TLS certificate. Additionally, plugin data stored within Vault lie behind the cryptographic barrier - ensuring that data is constantly encrypted throughout Vault.

Using a plugin is simple and requires no source code changes. A user wishing to add a plugin to their installation registers their plugin with the Plugin Catalog. Once the plugin has been registered, the user mounts the plugin with the following command:

$ vault mount -path=my-secrets -plugin-name=passthrough-plugin plugin

Where -plugin-name is the name of the plugin as defined in the Plugin Catalog.

For more details on creating and using plugins see: HashiCorp Vault plugins documentation

»Disaster Recovery

Note: This is a Vault Enterprise Pro feature

Disaster Recovery (DR) is a new form of replication introduced in Vault Enterprise Pro 0.8. Designed to solve the needs of business continuity in the face of a catastrophic failure of the entire primary cluster, DR allows the promotion of mirrored secondary clusters in a way that does not require that secondary to regenerate and distribute tokens previously distributed by the former primary.

This is critical, as the performance-focused version of replication Vault premiered in Vault 0.7 does not integrate this functionality and would thus require retokenizing all existing users and applications integrated with Vault. At scale, this is an onerous or even impossible task.

Introducing Disaster Recovery in 0.8 provides new options for how Vault users can architect multi-cluster and multi-data center environments.

Like Performance secondary clusters, secondary clusters linked to a primary in Disaster Recovery replication mirror the security infrastructure and configuration infrastructure of the primary cluster. Unlike their performance counterparts, DR secondary clusters do not forward read/write instructions like their performance secondary counterparts. They simply wait and mirror data from their primary, until elected to serve as the primary due to the primary’s failure.

It is possible however to create sophisticated architectures of primaries and secondaries to satisfy both the need to scale read write performance as well as satisfy disaster recovery needs by using a combination of performance replication and DR.

For example, in the above architecture Cluster A is replicating data to clusters B and C - both in separate, geographically distributed data centers or availability zones.

To satisfy the need to scale performance for users and applications in another part of the world, the Vault user has elected to have Cluster B located in a region physically closer to distant, large hub of applications using Vault. The user does this with Performance replication, and applications accessing secrets in Vault forward requests for reads and writes through B to the primary cluster, A.

To satisfy the needs to protect against catastrophic failure of A, the user also establishes Cluster C and links it to A with Disaster Recovery. This allows C to be elected to resume operations for A, and serve read/write requests to B without requiring applications to generate and authenticate new tokens for access to secrets.

It is possible to chain clusters together to satisfy a variety of performance and disaster recovery / compliance needs in a single infrastructure.

However, because of the nature of what data can and can not be forwarded from some secondary clusters, it is important to note a cluster’s existing replication relationships before attempting to have it serve as a primary for DR or Performance relationships:

Additionally it is critical to note that Performance Replication is a Vault Enterprise Premium feature, and as such only clusters using Vault Enterprise Premium may serve as a primary for Performance replication.

»Mount Filters

Note: This is a Vault Enterprise Premium feature

Mount Filters are a new way of controlling which secrets are moved across clusters and physical regions as a result of replication. With Mount Filters, users can select which mounts will be replicated as part of a Performance replication relationship.

Prior to Vault Enterprise 0.8, all non-local mounts and associated data are replicated as part of replication. Filters allow users to whitelist and/or blacklist which secret mounts are replicated, thereby allowing users to further control the movement of secrets across their infrastructure.

This is critical for satisfying a variety of government and regulatory compliance requirements for sensitive data. For example the EU’s Data-Protection Directive (DPD or Directive 95/46/EC) requires that personally identifiable data not be physically transferred to locations outside the European Union unless that region or country has an equal rigor of data protection regulations as the EU.

With Mount Filters, users can abide by data movement and sovereignty regulations while ensuring performant access across geographically-distributed regions. For example a company managing data that may have a subset of that data subject to Direct 95/46/EC may contain all DPD data on a single secret mount and blacklist movement of that data in a mount filter.

»Identities, Entities and Multi-Factor Authentication (MFA)

Note: This is a Vault Enterprise Premium Feature

Vault 0.8 introduces an entirely new Multi-Factor Authentication (MFA) system, as well as the foundations for a new identity management structure within Vault that we will iterate on in future releases.

Prior to Vault 0.8, Vault supported interacting with Duo MFA via an add-on capability within specific supporting authentication backends. This design of this system placed a lot of constraints on the types of MFA that could be supported and required work on the part of each backend author to specifically support it.

With Vault 0.8, users will now be able to explicitly govern access to secrets with MFA via ACL Policies. It is able to do this by taking advantage of a set of new core technologies in Vault referred to as Identity. Identity allows tracking Vault clients across tokens and ascribing metadata to clients for use by other subsystems and backends within Vault. It is debuting as an enabler of MFA support in 0.8 and will be the backbone of many new features going forward.

For example a user who wants to require Duo in an ACL policy would first instantiate an entity representing access to Duo:

PUT /sys/config/mfa/method/eng_duo
Request:
{
		"type": "duo",
		"data: {
				"skey": "799yBzHKBLk1gOK3mg416GMSPHWnI3Ad/SuwBwfM",
				"ikey": "VKIAJJQ3OIXWWGHEOZHA",
				"host": "api-InhP8wk.duosecurity.com"
		}
}

This entity would then be referenceable within a new field in ACL policies: mfa_methods

path "<path_name>" {
		capabilities = [...]
		allowed_parameters = {...}
		denied_parameters = {...}
		mfa_methods = ["eng_duo", "dev_totp"]
}

The entity construct is a new architectural piece of Vault, and part of a larger effort around unifying multiple types of system credentials into a single, logical identity within Vault.

Much like we introduced Performance replication and its foundations in 0.7 and iterated on these foundations with DR and mount filters in 0.8, we will be working on iterating and exposing new functionality in future releases of Vault to provide new ways of managing identities and access to secrets.

»Other Features

There are many new features in Vault 0.8 that have been developed over the course of the 0.7.x. Milestone releases beyond those we have described above. We have summarized a few of the larger features below, and as always consult the Changelog for full details.

• ed25519 Signing/Verification in Transit with Key Derivation - The Vault Transit backend now supports generating ed25519 keys for signing and verification functionality. These keys support derivation, allowing you to modify the actual encryption key used by supplying a context value.
• Key Version Specification for Encryption in Transit - Vault users can now specify the version of a key you use to wish to generate a signature, ciphertext, or HMAC. This can be controlled by the min_encryption_version key configuration property.
• Database Backend with Secure Plugins - A single database backend now encompasses the previous MSSQL, MySQL, and PostgreSQL backends into a much more scalable and flexible system. Additionally, plugins can be written to extend this functionality to other databases as per the Secure Plugins interface used for creating custom Auth and Secret backends.
• AWS IAM for Authentication - Support the use of AWS IAM principals for logging into Vault.
• TOTP Secret Backend - Vault supports the ingress and generation of TOTP codes for use in providing and validating 2FA codes.
• PROXY Protocol Support - Vault supports the use of the PROXY protocol for operating with load balancers.

»Upgrade Details

Vault 0.8 introduces significant new functionality. As such, we provide both general upgrade instructions, a Vault 0.8-specific upgrade page detailing breaking changes, as well as a configuration guide for deploying and managing replication incorporating updates for DR and mount filters.

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, go to 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 0.8!