Skip to main content

Kubernetes

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

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

Use cases​

Running a OpenBao Service: The OpenBao 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 OpenBao service running in Kubernetes can access and store secrets from OpenBao using a number of different secret engines and authentication methods.

Running a Highly Available OpenBao Service: By using pod affinities, highly available backend storage and auto-unseal, OpenBao can become a highly available service in Kubernetes.

Encryption as a Service: Applications using the OpenBao service running in Kubernetes can leverage the Transit secret engine as "encryption as a service". This allows applications to offload encryption needs to OpenBao before storing data at rest.

Audit Logs for OpenBao: Operators can choose to attach a persistent volume to the OpenBao cluster which can be used to store audit logs.

And more! OpenBao can run directly on Kubernetes, so in addition to the native integrations provided by OpenBao itself, any other tool built for Kubernetes can choose to leverage OpenBao.

Getting started with OpenBao and kubernetes​

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

High level comparison of integrations​

There are currently 3 different integrations to help Kubernetes workloads seamlessly consume secrets from OpenBao, without the need to modify the application to interact directly with OpenBao. 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 OpenBao. 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.

OpenBao CSI provider​

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