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:
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.
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.
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!
Explore the pros and cons of five different ways to manage credentials and other secrets in Terraform Cloud & Enterprise.
Several new partners have had their integrations validated for cloud-managed HCP Vault.
Learn how Vault can help you build zero trust security on Microsoft Azure with five common use cases and five best practices.