chore(sealed-secrets): commit controller manifest with key renewal disabled
Pins a single sealing key (--key-renew-period=0). Upstream rotates every 30d and kubeseal seals with the newest key, which would silently invalidate the off-cluster key backup for secrets sealed after a rotation. Includes DR runbook. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,26 @@
|
||||
# sealed-secrets
|
||||
|
||||
Controller v0.38.4, applied directly (not via ArgoCD — matches how cert-manager is handled;
|
||||
ArgoCD apps here are workloads, not cluster infra):
|
||||
|
||||
kubectl apply -f apps/sealed-secrets/controller.yaml
|
||||
|
||||
`controller.yaml` is the upstream release manifest plus ONE local change:
|
||||
`--key-renew-period=0`. Upstream defaults to rotating the sealing key every 30 days;
|
||||
kubeseal always seals with the newest key, so a rotation would silently invalidate the
|
||||
off-cluster key backup for anything sealed afterwards. Pinning to one key keeps the
|
||||
backup permanently valid. Rotation buys little here — it never re-seals existing secrets.
|
||||
|
||||
## Disaster recovery (order matters)
|
||||
|
||||
# 1. install controller
|
||||
kubectl apply -f apps/sealed-secrets/controller.yaml
|
||||
# 2. restore the private key BEFORE applying any SealedSecret,
|
||||
# or a fresh key is generated and nothing decrypts
|
||||
gpg -d /mnt/bulk/backups/sealed-secrets/master-key-YYYYMMDD.gpg | kubectl apply -f -
|
||||
kubectl -n kube-system rollout restart deploy/sealed-secrets-controller
|
||||
# 3. apply the SealedSecrets
|
||||
kubectl apply -f apps/cluster-secrets/ # cert-manager, argocd, solitaire
|
||||
# (apps/notesnook + apps/nightscout SealedSecrets come via ArgoCD)
|
||||
|
||||
Passphrase for the .gpg is in the password manager, and nowhere else.
|
||||
Reference in New Issue
Block a user