HCP Vault Secrets Centralized secrets lifecycle management for developers. Learn More
Vault
Vault Home

Kubernetes

Vault can be deployed into Kubernetes using the official HashiCorp Vault Helm chart. The Helm chart allows users to deploy Vault in various configurations:

  • Dev: a single in-memory Vault server for testing Vault
  • Standalone (default): a single Vault server persisting to a volume using the file storage backend
  • High-Availability (HA): a cluster of Vault servers that use an HA storage backend such as Consul (default)
  • External: a Vault Agent Injector server that depends on an external Vault server

Use cases

Running a Vault Service: The Vault server cluster can run 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 secret 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.

And more! Vault can run 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.

Getting started with Vault and kubernetes

There are several ways to try Vault with Kubernetes in different environments.

Guides

High level comparison of integrations

There are currently 3 different integrations to help Kubernetes workloads seamlessly consume secrets from Vault, without the need to modify the application to interact directly with Vault. Each integration addresses slightly different use-cases. The following is a brief overview of the strengths of each integration.

Agent injector

  • No durable secret storage outside Vault. All secrets written to disk are in ephemeral in-memory volumes.
  • No highly privileged service accounts required. All secrets are fetched with the pod's own service account without the need for any other service accounts to impersonate it.
  • More mature solution, with proven production record and advanced features like templating, wider array of auth methods, etc.

Vault Secrets Operator

  • More native UX for app developers. Workloads can mount Kubernetes secrets without adding any Vault-specific configuration.
  • Reduced load on Vault. Secrets are synced per CRD instead of per consuming pod.
  • Better Vault secret availability. Kubernetes secrets act as a durable cluster-local cache of Vault secrets.

Vault CSI provider

  • The CSI driver that the provider is based on is vendor neutral.
  • No durable secret storage outside Vault if the secret sync feature isn't used. All secrets written to disk are in ephemeral in-memory volumes.

Documentation

Edit this page on GitHub