openbao-gitops

Deploys OpenBao (standalone mode, file storage backend) as the cluster's central secret management backend, and wires up the External Secrets Operator (ESO) to read from it via Vault's Kubernetes auth method.

This chart wraps the official openbao-helm chart as a dependency and adds:

• A ClusterSecretStore (ESO CRD) pointing at the OpenBao service
• A one-time bootstrap Job (disabled by default) that enables the Kubernetes auth method, a read-only policy, and a role bound to ESO's ServiceAccount

Prerequisites

• ESO must already be installed in the cluster (deployed separately via the apps-in-apps repo) with a ServiceAccount named eso.serviceAccountName (default: external-secrets) in eso.namespace (default: external-secrets).

Deployment & manual init/unseal

OpenBao (like Vault) cannot be auto-initialized/unsealed when using file storage without a KMS auto-unseal mechanism, so this part is a manual, one-time step per environment:

1. Deploy this chart (via ArgoCD, see apps-in-apps) - or locally:

   helm dependency update .
   helm upgrade --install openbao . -n openbao --create-namespace
   

2. Initialize OpenBao (save the unseal keys and root token securely, e.g. in a password manager - they are NOT stored anywhere in git):

   kubectl exec -n openbao -it openbao-0 -- bao operator init
   

3. Unseal (repeat with 3 of the 5 unseal keys from step 2):

   kubectl exec -n openbao -it openbao-0 -- bao operator unseal
   

4. Store the root token as a Secret so the bootstrap Job can use it:

   kubectl create secret generic openbao-root-token \
     -n openbao --from-literal=token=<root-token-from-step-2>
   

5. Enable the bootstrap Job and re-sync (e.g. --set bootstrap.enabled=true via the ArgoCD Application's Helm parameters, or in values.yaml). It enables the KV v2 engine, the Kubernetes auth method, the eso-read policy and the eso-role role bound to the ESO ServiceAccount.

6. Confirm the ClusterSecretStore/openbao becomes Valid:

   kubectl get clustersecretstore openbao -o wide
   

After this, any namespace can create an ExternalSecret referencing the openbao ClusterSecretStore to pull secrets from OpenBao's secret/ KV mount.

Note: after a pod restart (upgrade, node reschedule, etc.) OpenBao comes back up sealed and must be unsealed again with the keys from step 2 unless you later configure an auto-unseal mechanism (e.g. Transit, cloud KMS) - out of scope for this initial setup.

Configuration

See values.yaml. Key settings:

Key	Description	Default
openbao.server.dataStorage.size	PVC size for OpenBao's data	10Gi
openbao.server.dataStorage.storageClass	StorageClass, empty = cluster default	""
eso.namespace / eso.serviceAccountName	Where ESO runs and which ServiceAccount to bind	external-secrets
eso.kvMountPath	KV v2 mount path used by the ClusterSecretStore	secret
bootstrap.enabled	Toggle the one-time auth/policy bootstrap Job	false