The External Secrets Operator (ESO) is the second pillar of Kubermatic SecureGuard. While OpenBao acts as the secure storage vault, ESO acts as the intelligent delivery mechanism.
In plain English: ESO is a delivery service. You keep your secrets locked in a vault (OpenBao). Your apps, however, only know how to read ordinary Kubernetes Secret objects. ESO is the courier that fetches a secret from the vault, drops a copy into a Kubernetes Secret where your app can pick it up, and keeps re-checking the vault so the copy never goes stale. Your app never has to know the vault exists.
New to the terms below (CRD, SecretStore, namespace)? See the Glossary.
A note on providers: These docs use OpenBao as the running example because it’s SecureGuard’s bundled default, but ESO is provider-agnostic. The same SecretStore → ExternalSecret flow works with AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, and many others — only the SecretStore’s provider block changes. Wherever you read “OpenBao” below, you can substitute your provider of choice.
ESO is an open-source Kubernetes operator designed to integrate external secret management systems directly into Kubernetes. Its primary job is to securely pull data out of OpenBao and inject it cleanly into the native Kubernetes namespaces where your applications actually run.
Historically, developers had to write custom SDK logic into their apps or deploy complex sidecar containers to retrieve secrets from systems like OpenBao.
With ESO deployed as part of SecureGuard, applications remain completely oblivious to OpenBao’s existence. Apps simply mount standard Kubernetes Secret objects (as volumes or environment variables). ESO continuously runs in the background, ensuring those standard Secret objects remain synchronized with the authoritative source (OpenBao).
ESO’s workflow is governed by four primary Custom Resource Definitions. SecureGuard provides the visual UI to manage these objects.
A SecretStore is a namespaced configuration that tells ESO how to connect to OpenBao.
It defines:
Functionally identical to a SecretStore, but scoped globally. A ClusterSecretStore allows an administrator to define a single connection to OpenBao that developers in any Kubernetes namespace can utilize.
The ExternalSecret is the core object managed by developers. It defines what to fetch.
It specifies:
SecretStore or ClusterSecretStore to use to reach the vault.kv/data/db/postgres).Secret that ESO should generate.The reverse flow. Often, components inside Kubernetes generate credentials (e.g., a database operator generates a root password). A PushSecret allows you to take an existing Kubernetes Secret and automatically push it upstream into OpenBao for safe, centralized storage and auditing.
In addition to the upstream ESO CRDs, SecureGuard introduces custom resources:
A cluster-scoped resource that configures event-driven workload reloading. When a synced Kubernetes Secret changes, the ReloaderConfig triggers rolling restarts of dependent Deployments, StatefulSets, or DaemonSets.
A namespaced resource managed by the SG Agent Controller. It defines the desired ESO installation state for a target cluster, including version, namespace, component configuration, and replica counts.
A cluster-scoped resource representing an agent registered with the central SecureGuard dashboard. SGAgents maintain heartbeat health status for connected clusters.
When evaluating an ExternalSecret, ESO uses a Reconciliation Loop.
refreshInterval: 1h).Secret.To summarize how OpenBao and ESO collaborate in SecureGuard:
SecretStore in Kubernetes configuring the connection to OpenBao using a Kubernetes Service Account.ExternalSecret referencing the SecretStore and the path to the credential.Secret, and continuously watches for any future updates.