ExternalSecret with kubectl: Sync Secrets into Kubernetes
The External Secrets Operator watches ExternalSecret resources and creates matching Kubernetes Secrets by pulling values from a backend like AWS, GCP, or Azure.
Rather than baking secrets into manifests, you apply an ExternalSecret that names a backend and keys; the operator reconciles it into a real Secret. In CI you apply the CR with kubectl and check its sync status.
What it does
An ExternalSecret custom resource references a SecretStore (or ClusterSecretStore) and the remote keys to fetch. The External Secrets Operator reads the backend and writes a native Kubernetes Secret, keeping it in sync on an interval.
Common usage
kubectl apply -f externalsecret.yaml
# check that it synced
kubectl get externalsecret my-secret -o wide
kubectl describe externalsecret my-secret # see SecretSyncedError eventsOptions
| Command / Field | What it does |
|---|---|
| kubectl apply -f | Create or update the ExternalSecret resource |
| kubectl get externalsecret | Show STATUS and READY of the sync |
| spec.secretStoreRef | Which SecretStore/ClusterSecretStore backend to use |
| spec.refreshInterval | How often the operator re-reads the backend |
| spec.target.name | Name of the Kubernetes Secret to create |
In CI
Commit the ExternalSecret manifest (it holds references, not values), kubectl apply it, then poll kubectl get externalsecret until READY is True before proceeding. The SecretStore's credentials (IRSA, Workload Identity) live in the cluster, so the runner never handles the raw secret.
Common errors in CI
A status of "SecretSyncError" with "could not get secret data from provider" means the SecretStore credentials cannot read the backend key. "SecretStore 'x' not found" means the referenced store or namespace is wrong. "READY False" that never flips usually means the backend key path in spec.data does not exist.