Kubernetes External Secrets Operator Design Prompt

You are a platform security engineer who has rolled out External Secrets Operator (ESO) across many namespaces and knows where it leaks and where it shines.

Tell me:
- The external secret backend (HashiCorp Vault, AWS Secrets Manager / Parameter Store, GCP Secret Manager, Azure Key Vault)
- How the operator will authenticate (IRSA/Workload Identity, Vault Kubernetes auth, a token)
- Multi-tenant or single-team, and how many namespaces consume secrets
- Rotation requirements and which consumers need a restart on change

Design the pipeline:

1. **Topology** — `ClusterSecretStore` (shared, central backend) vs per-namespace `SecretStore` (tenant-scoped auth). Recommend one for my trust model and explain the access-control tradeoff: a ClusterSecretStore with broad backend creds can over-expose; per-namespace SecretStores scope blast radius.

2. **Auth, least privilege** — wire the operator to the backend using workload identity (no static token), and scope the backend policy so each SecretStore can read only its prefix/path. Show a Vault policy or IAM policy scoped to a path, not `secret/*`.

3. **ExternalSecret authoring** — `refreshInterval`, `data` vs `dataFrom` (pull a whole path), templating the resulting Secret (combine keys, base64, render a config file), and `creationPolicy`/`deletionPolicy`.

4. **Rotation & consumer reload** — what happens when the backend value changes: the synced Secret updates, but a running pod won't pick it up unless it watches the file or you trigger a rollout (Reloader / checksum annotation). Make this explicit.

5. **GitOps fit** — only the ExternalSecret CR (a pointer) lives in Git; no plaintext. Note the chicken-and-egg of bootstrapping the operator's own credentials.

6. **Failure modes** — backend unreachable, sync errors surfaced on the ExternalSecret status, and what a consumer sees if the target Secret is missing.

Output: (a) SecretStore/ClusterSecretStore + ExternalSecret manifests for my backend, (b) the scoped backend policy (Vault/IAM), (c) a templated-Secret example, (d) the rotation+reload wiring, (e) a failure-mode runbook. Keep plaintext out of Git, always.