This guide walks you through the key features of the SecureGuard dashboard. It assumes you have a running deployment (see Getting Started) and are logged in.
SecureGuard is, by design, mostly a read-only “control room.” It is built to give you safe visibility into your secret-syncing setup, plus a few safe day-2 operations — without ever exposing secret values and without turning the browser into a general-purpose Kubernetes editor.
Most ESO resources (ExternalSecrets, SecretStores, PushSecrets, ReloaderConfigs)
are created and edited outside the dashboard — with kubectl or your GitOps
tool (Argo CD, Flux) — so they live in version control and code review. The
dashboard then lets you watch, troubleshoot, and run targeted actions on them.
| Resource | View | Create | Edit | Delete | Other actions |
|---|---|---|---|---|---|
| ExternalSecret | ✅ | — | — | ✅ | Sync Now (force a refresh) |
| SecretStore / ClusterSecretStore | ✅ | — | — | — | — |
| PushSecret | ✅ | — | — | ✅ | — |
| Kubernetes Secret | ✅ (masked) | — | — | — | — |
| ReloaderConfig | ✅ | — | — | ✅ | — |
| ESODeployment | ✅ | ✅ | ✅ | ✅ | Guided create/edit form |
| Cluster | ✅ | ✅ (upload kubeconfig) | — | ✅ | Health check |
| Federation (Server / Authorization) | ✅ | — | — | — | — |
Why so read-only? Each thing the browser can do must be explicitly allowed by the proxy’s route allowlist. Keeping the surface small is a deliberate security choice — see Architecture → Security Model. To create the resources marked “—” above, use kubectl apply or GitOps.
The Dashboard page provides an at-a-glance view of your secrets management posture:
Navigate to External Secrets in the sidebar. The table shows all ExternalSecrets across your selected namespace(s) with:
Synced (green), Pending (amber), Error (red), or StaleUse the search box and the Status / SecretStore filters to narrow the list.
An ExternalSecret is flagged Stale when its last successful sync is older than twice its refreshInterval — a sign that ESO is running but silently failing to refresh (provider unreachable, credentials expiring, controller wedged). Stale secrets get their own dashboard metric and list filter so they don’t hide behind a green Synced condition.
Click any row to open the detail view, which includes:
spec.data / spec.dataFrom) and target template••••••••)For an errored ExternalSecret, the detail view offers a Debug action that opens the Sync Error Drawer: a side panel combining the resource’s condition timeline, related Kubernetes events, and remediation hints — pattern-matched suggestions for common failures (e.g. access denied → check the provider policy attached to the store’s role). This is usually the fastest path from a red badge to a root cause without leaving the browser.
ExternalSecrets are not created from the dashboard. Create them with
kubectl or your GitOps tool so they stay in version control. A minimal example:
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: db-creds
namespace: default
spec:
refreshInterval: 1h
secretStoreRef:
name: my-store # an existing SecretStore/ClusterSecretStore
kind: SecretStore
target:
name: db-creds # the Kubernetes Secret ESO will create
data:
- secretKey: password # key in the created Secret
remoteRef:
key: secret/db/postgres # path in the provider
property: password # field at that path
kubectl apply -f db-creds-externalsecret.yaml
Within a few seconds it appears in the dashboard’s External Secrets list, where you can watch it sync. (See ESO Basics for what each field means, and the Glossary for the terms.)
From an ExternalSecret’s detail view you can:
force-sync annotation; ESO reacts to it.) Use this after rotating a value in
the provider and wanting it reflected right away.kubectl
/ GitOps, then re-viewed here.SecretStores define how to connect to an external secret provider (OpenBao, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, etc.).
Both types are managed from the Secret Stores page. Use the tab selector to switch between the two.
SecretStores are view-only in the dashboard — create and edit them with
kubectl or GitOps. The list shows each store’s provider and its Ready
status; the detail view shows the full configuration as read-only YAML and the
store’s status conditions.
When you look at a store’s configuration, note that credential fields are references, not raw values: a store points to an existing Kubernetes Secret (by name and key) that holds the actual provider credentials — the dashboard never shows or accepts the credentials themselves.
PushSecrets are the reverse flow — they push Kubernetes Secrets upstream to an external provider.
On the Push Secrets page you can view all PushSecrets and their sync
status, open a detail view, and delete a PushSecret. Creating a PushSecret is
done with kubectl or GitOps (the dashboard has no create form). A PushSecret
specifies the source Kubernetes Secret, the target SecretStore, the destination
path in the provider, and which keys to push.
The Secrets page lists all Kubernetes Secrets in the selected namespace(s). For each secret:
••••••••This page is view-only — Kubernetes Secrets are created and updated by ESO (from your ExternalSecrets), not edited by hand in the dashboard.
ReloaderConfigs make secret delivery event-driven: they wire notification sources to trigger destinations, so a change propagates the instant it happens instead of on ESO’s next poll. On the Reloaders page you can view all ReloaderConfigs and their status, open a detail view (with Notification Sources and Trigger Destinations tabs), and delete one. They are created with kubectl / GitOps and specify:
Secret or ConfigMap change, a cloud event (GCP Pub/Sub, AWS SQS, Azure Event Grid), a HashiCorp Vault audit-log event, a generic webhook, or a TCP socket.Common patterns: restart a Deployment when its Secret rotates, or trigger ESO to re-fetch on a cloud event/webhook rather than waiting for refreshInterval. See the External Secrets Reloader docs for the full source/destination catalog.
ESODeployments manage the ESO operator lifecycle across clusters — the one resource with a full create/edit form in the dashboard:
Deploying, Running, Upgrading, Deleting, Error, and Discovered (see below)The guided form validates as you type and covers:
latest-flagged release preselectedA Form ↔ YAML toggle lets you switch to a full YAML editor at any point — the round-trip is lossless, so YAML keys the form doesn’t know about are preserved.
Before you submit, the form checks the new deployment against existing ESODeployments on the same effective cluster and warns about:
The SG Agent performs the same checks server-side and surfaces violations as a Conflict condition on the resource — blocking (Error) or advisory (Warning) depending on severity.
The SG Agent periodically scans connected clusters for ESO installations it didn’t deploy (e.g. installed by another platform team). These appear as read-only eso-ext-* ESODeployments in the Discovered phase with managementMode: external, showing the discovered image and replica count. SecureGuard never modifies them — they exist so the dashboard shows the complete picture. To adopt such a cluster, remove the external installation and create a managed ESODeployment for it.
The Federation page provides read-only visibility into cross-cluster secret distribution — letting a central SecureGuard instance serve secret data to many clusters without exposing the backend stores. It has two tabs:
FederationServer resources, which declare what the broker
exposes (backend stores) and which token issuers it trusts, with Ready status.FederationAuthorization policies, which grant a specific
remote identity read access to specific stores and key globs (deny-by-default).These resources carry references and policy only — never secret values.
Secret serving happens in the separate federation broker, not in the dashboard
proxy. Federation is opt-in and disabled by default. For setup, the broker, the
fedclient consumer, and resolution modes, see the Federation guide.
The Event Stream page shows a live feed of Kubernetes events related to ESO resources, aggregated across all selected clusters. Use it for:
kubectlControls: filter by Type (Normal/Warning) and Reason, Pause/Resume the feed, and Clear the buffer. Each event links to its involved object’s detail page. The feed polls every 10 seconds and keeps the most recent 500 events.
The Visualization page renders your secret-syncing topology in two views:
Click any node to navigate to its detail page. Both views respect the global cluster and namespace selectors.
The cluster selector in the top bar lets you scope the view to a specific cluster or view resources across all clusters. In “All Clusters” mode the dashboard queries every registered cluster in parallel and tags each row with its origin cluster. The selection is persisted in the URL (?cluster=...), so filtered views are shareable and bookmarkable.
Navigate to Clusters (the Cluster Management page) and click Add Cluster. A three-step wizard walks you through registration:
kubectl commands to run against the target cluster: they create a dedicated least-privilege, read-only ServiceAccount for SecureGuard. Use Copy All Commands and run them with cluster-admin rights on the target.On upload, the proxy immediately replaces the kubeconfig’s credential with a short-lived, self-renewing token — the uploaded credential is never persisted. See Short-Lived Remote-Cluster Tokens.
The Cluster Management page shows the health of all connected clusters, their environment, an SG Agent badge (active / stale / none) with the last heartbeat, and per-cluster actions:
Unhealthy clusters are flagged with the reason (unreachable, auth expired, etc.). The cluster detail page additionally shows the SG Agent’s status conditions and the ESODeployments targeting that cluster.
The namespace selector in the top bar filters all views by namespace. Select “All Namespaces” to see resources across the entire cluster.
The selected namespace is persisted in the URL (?namespace=...), making it shareable and bookmarkable.
As you use the dashboard, keep these security principles in mind: