Type '/' to Search

»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

»Documentation