🔐 OpenBao on Kubernetes: Agent Injector vs CSI Provider vs External Secrets Operator

Three ways to get secrets into a pod — and why the “simplest” one is also the one most likely to leak yours into etcd.

Introduction

A default Kubernetes Secret is base64, not encryption — anyone with get secrets RBAC and etcd access can read it in plaintext. That single fact drives most of the architecture decisions in this article. OpenBao, the Linux Foundation fork of HashiCorp Vault, solves secret storage and rotation at the source, but getting a secret from OpenBao into a running pod is not one problem — it's three competing ones, each with a different trust boundary. The Agent Injector puts a sidecar in every pod and keeps secrets in memory. The Secrets Store CSI Driver mounts them into tmpfs through a node-level driver, no sidecar required. External Secrets Operator (ESO) takes the opposite bet: it syncs OpenBao values into native Kubernetes Secrets so your application never has to know OpenBao exists. All three now ship OpenBao-native support — openbao-csi-provider, the OpenBao Agent Injector fork, and ESO's Vault-compatible provider — so the choice is no longer "which one works with OpenBao," it's "which trust and operational trade-off does your workload actually need." This article scores all three against a single production cluster running mixed workloads: legacy apps, high-security payment services, and everything in between.