HashiCorp Vault 1.1 Adds Secret Caching and Transit Auto Unseal

HashiCorp has released version 1.1 of Vault, their secrets and identity management tool. With this release there is now support for secret caching by Vault Agents, authentication to Vault via OpenID Connect, and using a Vault cluster to auto unseal another Vault cluster via transit encryption.

With support for secret caching via the Vault Agent, there is now client-side caching of leased secrets. This caching works with the Auto-Auth feature to permit caching of tokens and leased secrets requested through an agent that has access to the auto-auth token. The Vault Agent will manage the lifecycle of the cached tokens and secrets automatically.

Cache evictions are handled by the Vault Agent when it can no longer renew the lease on either the token or the secrets. Some best effort cache eviction is also performed, for example, a successful token revocation request will result in all associated cache entries being evicted. Since it is possible for the agent to be unaware of some revocations, such as through direct client interactions, an endpoint has been exposed to allow for manual cache evictions.

Enabling client side caching requires that the auto-auth and cache values be specified in the Vault Agent configuration file:

$ cat vault-agent.hcl

exit_after_auth = false
pid_file = "./pidfile"

auto_auth {
   method "aws" {
       mount_path = "auth/aws"
       config = {
           type = "iam"
           role = "app-role"
       }
   }

   sink "file" {
       config = {
           path = "/home/ubuntu/vault-token-via-agent"
       }
   }
}

cache {
   use_auto_auth_token = true
}

listener "tcp" {
   address = "127.0.0.1:8200"
   tls_disable = true
}

vault {
   address = "http://<vault-server-host>:8200"
}

Similar to the release of batch tokens in Vault 1.0, the addition of client-side caching helps to relieve pressure on the storage backend. Batch tokens are encrypted blobs that allows for Vault actions but require no storage on disk for tracking purposes. However, batch tokens do not provide the same level of features as service tokens do, resulting in use cases where batch tokens would not suffice.

Vault Agent caching utilizes service tokens created through auto-auth allowing for the same use cases that service tokens already provide. The token caching will help minimize the storage impact of service tokens by reducing the I/O impact to the Vault cluster for access of secrets.

The addition of transit auto unseal allows for use of the transit secret engine in another Vault cluster as the auto unseal provider. This allows for a second cluster to serve as the external root of trust for use cases where another compliant HSM or KMS is available. The Transit seal is configured by either adding the seal "transmit" block into Vault's configuration file or the presence of the environment variable VAULT_SEAL_TYPE set to transit. The following shows an example configuration of the Transit seal via the Vault configuration file:

seal "transit" {
  address            = "https://vault:8200"
  token              = "s.Qf1s5zigZ4OX6akYjQXJC1jY"
  disable_renewal    = "false"

  // Key configuration
  key_name           = "transit_key_name"
  mount_path         = "transit/"
  namespace          = "ns1/"

  // TLS Configuration
  tls_ca_cert        = "/etc/vault/ca_cert.pem"
  tls_client_cert    = "/etc/vault/client_cert.pem"
  tls_client_key     = "/etc/vault/ca_cert.pem"
  tls_server_name    = "vault"
  tls_skip_verify    = "false"
}

The addition of OpenID Connect (OIDC) allows for logins to Vault to be handled by an existing Single Sign On (SSO) service as long as that service supports the OIDC Provider system.

Other features included in this release include:

• InfluxDB plugin to allow Vault to create and manage users
• ACL path wildcarding allowing for + to be used as a wildcard matching a single directory in the path definition
• CLI commands can now include the flag -output-curl-string to output a cURL equivalent

Vault 1.1 does introduce breaking changes for users on older versions of Vault. HashiCorp has released an upgrade guide to assist in the upgrade process. The major breaking changes include removal of CLI commands that were deprecated in the 0.9.2 release and dropping of support for netRPC plugins in lieu of gRPC.

More information about the 1.1 release of Vault can be found on the HashiCorp blog. The open source version of Vault is available for download and readers interested in the Enterprise version of Vault can find more information on the HashiCorp website.