Get an overview of the most common ways to use HashiCorp Vault and Kubernetes together, and get a preview of a new method we're considering.
This blog post will look at the core integrations and use cases for how people are using HashiCorp Vault and Kubernetes together. We’ll discuss things like how to get up and running, options for injecting secrets, and where use cases are going in the future.
Over the past few years our goal has been to release a variety of options around how you can use Vault to securely introduce secrets into your Kubernetes applications. We know that each application deployment is different, and not all companies are the same when it comes to weighing security and implementation tradeoffs, so our goal is always to offer several Kubernetes integration options that serve a variety of applications and use cases. Let’s start by looking at the current integrations and use cases.
Historically, the most secure way to interact with Vault when fetching a secret was for the application to directly integrate with the Vault API. However, this often requires the application to be written or rewritten with Vault awareness, and this is not realistic for many workloads. From the beginning, the Vault team has worked alongside the Kubernetes community and customers running large deployments to flesh out the core use cases and develop great integrations that avoid the need for direct application integration.
Many Vault and Kubernetes integrations require little to no knowledge of HashiCorp Vault to source secrets from it, and that was by design. Here’s a list of the core integrations and use cases:
We have a production-ready Helm chart that will get you up and running quickly. This integration method can greatly reduce the complexity of running Vault on Kubernetes or accessing an external Vault cluster, and it gives you a repeatable deployment process in less time (versus rolling your own). The chart is highly customizable, using smart defaults tuned for an optimal getting started experience, and it has options for dev mode, integrated storage, external clusters, OpenShift, and much more.
By far, the most common integration and use case is injecting Vault secrets into Kubernetes pods via a sidecar agent. This method enables applications on Kubernetes to source static and dynamic secrets from Vault with no native Vault logic built-in. This integration is powered by a tool called vault-k8s, which leverages a Kubernetes mutating admission webhook to intercept and augment annotated pods for secret injection using init and sidecar containers. We recently released version 1.0.1 and have seen customers with hundreds of thousands of pods use this integration to deliver Vault secrets to Kubernetes workloads at scale.
The video below demonstrates how the Helm chart and agent sidecar injector tools work. The video walks through the initial vault-k8s setup using the Vault Helm chart and covers three example use cases: adding annotations, output formatting, and background jobs.
The Kubernetes auth method can be used to authenticate with Vault using a Kubernetes service account token. This method of authentication makes it easy for Vault and Kubernetes to associate and tightly control what secrets your workloads have access to.
We have a Kubernetes secrets engine for dynamically generating Kubernetes service account tokens, service accounts, role bindings, and roles. After the Kubernetes secrets engine has been configured, and a user has authenticated to Vault, you can write to the endpoint and Vault will generate a new service account token. This secrets engine provides a streamlined workflow to both developers and operations staff who need short-lived access to Kubernetes clusters.
At a high level, the Vault CSI provider enables pods to consume Vault secrets from files using CSI Secrets Store volumes. One difference from the agent sidecar injector is that the CSI provider saves on resources, since it does not require any sidecar containers. The Vault CSI provider is deployed as a DaemonSet and renders secrets before the pod starts. It also provides a method to sync secrets into environment variables via Kubernetes secrets.
We are talking with large scale users of vault-k8s to help us learn about ways to improve the integration. At HashiConf Global, we shared our intention to enhance vault-k8s with an operator approach. This operator could be used to periodically sync a subset of Vault secrets to Kubernetes secrets for applications to consume without directly interacting with Vault.
We believe this will provide both a better developer experience and more native Kubernetes experience. The developer experience will be improved, since Vault secrets will be easily accessible through the Kubernetes API as well as environment variables via Kubernetes secrets. Further, the Kubernetes native experience is improved since a resource that maps a Vault secret to Kubernetes secret can be expressed as a custom resource definition (CRD). This means application YAML no longer has to be directly "Vault aware" with Vault annotations. There are two other significant operational benefits:
To learn more about these integrations and their use cases, please check out our self-guided Vault and Kubernetes tutorials, videos, and hands-on labs, which are all available via HashiCorp Developer, our newly updated developer site. Don’t miss the 19 tutorials in the dedicated Vault on Kubernetes section, which include installing Vault via Helm, Injecting Secrets, the Vault CSI Provider, and much more.
Read our recap of HashiCorp security and networking news and developments on AWS from this past year.
Accelerate your adoption of a cloud operating model. Visit us at AWS re:Invent in Las Vegas, Nov. 28 - Dec. 2 for breakout sessions, expert talks, and product demos.
As next-generation 5G begins to take shape, learn about a suite of comprehensive, identity-based security solutions for microservice environments.