HashiCorp Vault 0.7

HashiCorp Vault 0.7

Mar 21 2017 Andy Manoske

We are proud to announce the release of HashiCorp Vault 0.7. Vault provides secrets management, encryption as a service, and privileged access management.

There is a necessary shift as traditional network-based approaches to security are being challenged by the increasing adoption of cloud and an architectural shift to highly elastic and microservice-oriented architectures. Organizations now must thread security within the application in addition to relying on perimeter-based security and traditional firewalls. Vault provides a necessary last line of defense to secure any application infrastructure.

Vault 0.7 adds major new functionality to both open source and enterprise versions. Highlights include:

The release includes additional new features, secure workflow enhancements, general improvements, and bug fixes. The Vault 0.7 Changelog provides a full list of features, enhancements, and bug fixes. Also, note that some of these changes occurred in Vault 0.6.5, but were not covered in previous blog posts. As always, we send a big thank-you to our community for their ideas, bug reports, and pull requests.

Multi-Datacenter Replication

Enterprise-Only Feature: This feature requires Vault Enterprise.

Many organizations have diverse infrastructure in geographically-distributed data centers across many clouds. For them, Vault provides the critical services of secrets storage, encryption as a service, and policy and access management for those secrets.

Prior to 0.7, Vault was restricted to pairing with other, local nodes into a single cluster. In this architecture, an active node would coordinate with a number of standby nodes to ensure high availability: when an active node was brought offline or experienced a failure, a standby node would automatically become active and take over servicing client requests.

While clusters provide high availability, there are some limitations:

  • The geographically-distributed nature of many organizations’ infrastructures often imposes performance and/or security limitations on applications that attempt to use secrets from a location physically far away from the cluster. Additionally, clusters were intended to have their nodes be located in a single data center (or otherwise physically “close” to each other in the cloud) due to the frequent communication that active nodes have with their standbys and storage backend.

  • Having single-active clusters requires scaling Vault vertically to handle the needs of an increasing number of clients.

With Vault 0.7, we are introducing the concept of multi-datacenter replication. Replication allows geographically-distributed clusters to pair in order to increase read performance globally and scale workloads horizontally across clusters. As this happens at the cluster level, each cluster can be part of a replication set and also maintain HA characteristics. Vault Replication Architecture Clusters pair in a leader/follower model. One cluster is elected as the primary cluster or simply primary. This is the master register of secrets, access policies, and configurations.

Secondary clusters (or simply secondaries) are clusters that follow changes written to the primary in near real-time and allow secrets, policies, and configurations from the primary to be mirrored to the secondary cluster. Each secondary is responsible for its own token and lease management, which allows for horizontal scaling by not requiring all client requests to be sent back to the primary to fulfill; instead, only requests that would change Vault’s underlying state need to be forwarded to the primary, in a step that is completely transparent to the client.

This architecture allows Vault deployments to scale horizontally. Vault clusters can be placed closer to remote users and applications in order to minimize the performance implications of latency due to distance. Similarly, as replicas of the primary’s configuration and static data, secondaries can help offload many Vault operations from the primary and help fast-growing infrastructures scale in the face of heavy demand.

Vault replication can be configured and managed using the Vault Enterprise web UI. The UI abstracts the complexity for setting up multi-datacenter replication. This allows a Vault user to set up replication within a few clicks. The below screenshots show the Enterprise UI for replication. Vault Replication Architecture For more information on how to set up and deploy replication in Vault Enterprise, see the Vault Enterprise documentation. To enable Vault 0.7’s Replication feature, we built a significant amount of technology into Vault’s core functionality. In the future, we are looking to build on this underlying replication technology to explore other use cases beyond scaling performance, such as disaster recovery capabilities.

Multi-datacenter replication is part of Vault Enterprise. For more information about HashiCorp Vault Enterprise, go to https://www.hashicorp.com/products/vault/.

Parameter-Scoped ACLs

Since its inception, Vault’s access control capability has centered around authorizing access to API endpoints. In early versions of Vault, the granularity of authorization was limited to simply “read” and “write” values. In this scenario, “write” translated to creating, updating, and deleting values:

path “secret/foo/*” { policy = “write” }

In Vault 0.5 we split these two options into sets of capabilities: “create”, ”update”, “read”, “delete”, and “list”. This allowed more fine-grained control over the actions that clients were allowed to take. For instance, you could now allow clients to create values in Vault’s “generic” K/V backend but not allow them to then change or remove those values, helping to ensure that important secrets could not be accidentally lost or overwritten:

path “secret/foo/*” { capabilities = [“create”, “read”, “list”] }

In Vault 0.7, the ACL system allows even finer-grained control: the ability to not only specify the actions that can be taken against a particular API path, but also the parameters that are allowed to be set (or must not be set) by a client making such a call:

path “secret/foo/*” { capabilities = [“create”, “read”, “list”] denied_parameters = { “ssn” = [] } }

The above ensures that no value written under “secret/foo” contains a parameter by the name “ssn”. You can even go a step further and provide acceptable (or not acceptable) values:

path “secret/foo/” { capabilities = [“create”, “read”, “list”] allowed_parameters = { “datacenter” = [“us-”, “dublin”] “*” = [] } }

The last example will allow any parameter to be set (the “*” entry is because once an “allowed_parameter” list is declared it acts as a whitelist), but if “datacenter” is one of those parameters it can only be set to “dublin” or a value beginning with “us-”.

In addition, “min_wrapping_ttl” and “max_wrapping_ttl” can be used to control response wrapping behavior. For example, the following will require all responses to be response-wrapped but mostly let the client pick for how long by setting the minimum to one second:

path “secret/foo/*” { capabilities = [“create”, “read”, “list”] min_wrapping_ttl = “1s” }

The examples above are relatively contrived, but there are a great many real-world uses of this capability.

In one example, an administrator may want to allow an operator to create SSH roles to enable clients to retrieve SSH credentials. Although the operator is trusted, the administrator practices defense-in-depth and wants to ensure that certain features of the role cannot be changed by the operator: namely, that the type of credentials must be certificates and they must be user certificates (as opposed to host certificates). The administrator can write the following policy:

path “ssh/roles/” { capabilities = [“update”, “read”, “list”, “delete”] allowed_parameters = { “key_type” = [“ca”] “” = [] } denied_parameters = { “allow_host_certificates” = [true] } }

As a second example, consider the PKI

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now