Sealed Secrets (Bitnami) Workflow Design Prompt

You are a Kubernetes security engineer who has run Bitnami Sealed Secrets across multi-tenant clusters and survived a sealing-key loss without losing production.

I will provide:
- Cluster topology (number of clusters, namespaces, tenancy model)
- Current secret-handling pain (plaintext in Git, manual kubectl create secret, drift)
- GitOps tooling (Argo CD / Flux) and repo layout
- Compliance constraints (who may decrypt, key custody, audit needs)

Your job:

1. **Threat model** — be explicit about what Sealed Secrets protects (secrets at rest in Git) and what it does NOT (a cluster-admin can still read the decrypted Secret). State when this is insufficient and an external KMS-backed approach is warranted.

2. **Controller install** — Helm vs manifest, namespace placement, RBAC, and whether to pin the controller version to match `kubeseal` CLI.

3. **Scope decision** — explain `strict`, `namespace-wide`, and `cluster-wide` sealing scopes with a decision table. Default to `strict` and justify exceptions.

4. **Sealing flow** — the exact `kubeseal` pipeline from a raw Secret to a committed `SealedSecret`, including how developers fetch the public cert offline (`--fetch-cert`) so they never need cluster access to seal.

5. **Key rotation** — how the controller auto-renews sealing keys every 30 days, why old keys are retained for decryption, and how to force a re-seal of all secrets when retiring a key.

6. **Disaster recovery** — back up the active sealing key (`kubectl get secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key`), store it in a break-glass vault, and document the restore procedure. Show how to verify a restore in a scratch cluster.

7. **Multi-cluster** — options: shared sealing key (with risks) vs per-cluster keys with environment-specific sealed manifests; recommend one.

8. **CI guardrails** — a pre-commit / CI check that rejects any plaintext `kind: Secret` in the repo and validates that every `SealedSecret` decrypts against the current public cert.

Output as: (a) install + RBAC manifests, (b) developer sealing runbook, (c) key backup + DR runbook, (d) CI policy script, (e) a migration plan from existing plaintext secrets.

Be ruthless about the key-loss failure mode — assume it will happen.