Announcing the HashiCorp Vault Helm Chart

This week we're releasing an official Helm Chart for Vault. Using the Helm Chart, you can start a Vault cluster running on Kubernetes in just minutes. This Helm chart will also be the primary mechanism for setting up future roadmapped Vault and Kubernetes features. By using the Helm chart, you can greatly reduce the complexity of running Vault on Kubernetes, and it gives you a repeatable deployment process in less time (vs rolling your own).

The Helm chart will initially support installing and updating the open-source version of Vault in three distinct modes: Single Server, Highly-Available (HA), and Dev mode. We are actively working on a version for Vault Enterprise and it will be available in the future. The Helm chart allows you to run Vault directly on Kubernetes, so in addition to the native integrations provided by Vault itself, any other tool built for Kubernetes can choose to leverage Vault.

Here are a few common use-cases for running Vault on Kubernetes:

• Running Vault as a Shared Service: The Vault server cluster runs directly on Kubernetes. This can be used by applications running within Kubernetes as well as external to Kubernetes, as long as they can communicate to the server via the network.
• Accessing and Storing Secrets: Applications using the Vault service running in Kubernetes can access and store secrets from Vault using a number of different Secret Engines and Authentication Methods.
• Running a Highly Available Vault Service: By using pod affinities, highly available backend storage (such as Consul) and Auto Unseal, Vault can become a highly available service in Kubernetes.
• Encryption as a Service: Applications using the Vault service running in Kubernetes can leverage the Transit Secrets Engine as "encryption as a service". This allows applications to offload encryption needs to Vault before storing data at rest.
• Audit Logs for Vault: Operators can choose to attach a persistent volume to the Vault cluster which can be used to store audit logs.

»Video

To learn more about the Vault Helm chart, watch the video below or scroll down to read more. The video below shows the Helm chart being used to install and configure Vault in each of the supported modes (dev. single server, and highly-available) on a 5 node Kubernetes cluster.

»Running a Vault Cluster

To use the Helm chart, you must download or clone the hashicorp/vault-helm GitHub repository and run Helm against the directory. When running Helm, we highly recommend you always checkout a specific tagged release of the chart to avoid any instabilities from master.

After downloading the repository, please check out a tagged release:

# Clone the repo
$ git clone https://github.com/hashicorp/vault-helm.git
$ cd vault-helm

# checkout a tagged version
$ git checkout v0.1.0

As mentioned earlier, the Helm chart supports three distinct modes: Single Server, Highly-Available (HA), and Dev mode. The default when using this Chart without options, is running Vault in Single Server mode, where it will provision a Volume for you and use that to store your data.

Then, install the chart:

# Install the chart
$ helm install --name=vault .

In just a minute, you'll have a standalone Vault pod deployed on Kubernetes. However, the Vault still needs to be initialized and unsealed, and we can verify that by checking the status.

# Check status
$ kubectl exec -it vault-0 -- vault status

So, let’s initialize the Vault instance.

# Initialize
$ kubectl exec -it vault-0 -- vault operator init -n 1 -t 1

Finally, let’s unseal the vault so we can use it.

# Unseal vault
$ kubectl exec -it vault-0 -- vault operator unseal <unsealkey>

Note that if we would have used the Dev mode to install the helm chart, the Vault instance would be automatically initialized, unsealed and using in-memory storage.

# Alternative - install the chart in dev mode
$ helm install --name=vault --set='server.dev.enabled=true' .

You now have a fully functional Single Server Vault service sitting in your Kubernetes cluster and you can start routing traffic to it. There is an obvious problem here, where we are using a single Pod instance and file backed storage, and this is a single point of failure. This is where the Highly-Available (HA) mode comes into play. You can read more about HA mode via the configuration options available in the values.yaml file found in the hashicorp/vault-helm GitHub repository, or through the Vault Helm Chart documentation.

»Next Steps

The Helm chart is available now on GitHub. We also plan to transition to using a real Helm repository soon. To learn more, see the Helm Chart documentation or the documentation on Running Vault on Kubernetes. Also, if you enjoy playing around with this type of stuff, maybe you’d be interested in working at Hashicorp too since we’re hiring!