The State of Vault and Kubernetes, and Future Plans

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.

»Vault and Kubernetes 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:

»Helm Chart

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.

»Agent Sidecar Injector

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.

»Kubernetes Auth Engine

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.

»Kubernetes Secrets Engine

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.

»Vault CSI Provider

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.

»Future Plans

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:

• Increased efficiency: Reduces resource consumption since a Vault sidecar is no longer needed for each app pod, and client requests to the Vault cluster are significantly reduced.
• Greater availability: Kubernetes secrets act as a local secret cache in the Kubernetes cluster, which means secrets are available even if the Vault cluster is temporarily unavailable while pods are restarting.

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.