HashiCorp Vault 0.7

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:

• Multi-datacenter replication (Enterprise)
• Parameter-scoped ACLs
• SSH backend as a Certificate Authority

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. 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. 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 backend, where authorized users can retrieve TLS certificates. The backend allows specifying a set of allowed domain names (e.g. “example.com”) and controlling whether the domain name itself or simply subdomains (including host names, such as “mymachine.example.com”) are allowed. Because each client has authorization to retrieve a certificate, in most cases having this level of granularity is sufficient since the certificates are being used more to ensure that both endpoints in a conversation were authorized within Vault rather than to prove a specific identity. There are times, however, when it can be useful to be able to prove that a machine belongs to a given group rather than simply that it was able to talk to Vault. One way to do this would be to look at the common name of the machine’s issued certificate. In the following example, clients given this policy can retrieve a certificate to show that they are an authorized FTP server but are not allowed to retrieve a certificate with a common name that might identify them as a database server:

path “pki/issue/myrole” {
    capabilities = [“update”]
    allowed_parameters = {
        “common_name” = [“ftp*”]
        “*” = []
    }
}

The PKI backend also allows setting Organization and Organizational Unit values per-role, providing another easy method of identification, but the example mechanism can be used to control behavior at the policy level rather than the role level.

More information about these new features can be found on the ACL Concepts page.

»Other Features

There are many new features in Vault 0.7 beyond replication. We have summarized a few of the larger features below, and as always consult the Changelog for full details.

• SSH Backend as a Certificate Authority: Vault may now be configured to serve as a certificate authority for SSH certificates. This extends the existing capability to generate One-Time-Passwords and dynamic RSA keys with a simpler option for some environments.
• Okta Authentication: Okta usernames and passwords may now be used to authenticate with Vault.
• Radius Authentication: RADIUS servers may now authenticate with Vault, and policies can be configured for specific users or for any authenticated user.
• Enterprise Usability Enhancements: There is continued enhancement of the Vault GUI capabilities of Vault Enterprise and Vault Pro. Transit layer operations and response wrapping are all now manageable from within the UI, and the new replication features in Vault 0.7 can be managed and configured within Vault Enterprise.

»Upgrade Details

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

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.

HashiCorp Vault 0.7 is available today. 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.7!