From fb124201bb0fa6e83390c4f5b0a195102004e244 Mon Sep 17 00:00:00 2001 From: Scooby Husky Date: Mon, 17 Aug 2026 21:54:21 -0500 Subject: [PATCH] Fix vault-restore RBAC: add watch verb for kubectl wait Without it, kubectl wait's internal watch retry loop never terminates cleanly even with --timeout set - confirmed live, it kept retrying well past the stated 120s timeout. The restore/unseal steps themselves still succeed regardless (verified end-to-end with a manual unseal), this only affects the job's own graceful detection of the pod coming back. Co-Authored-By: Claude Sonnet 5 --- .../vps-standby/vault/manifests/restore-cronjob.yaml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/infrastructure/vps-standby/vault/manifests/restore-cronjob.yaml b/infrastructure/vps-standby/vault/manifests/restore-cronjob.yaml index cca4e91..513a542 100644 --- a/infrastructure/vps-standby/vault/manifests/restore-cronjob.yaml +++ b/infrastructure/vps-standby/vault/manifests/restore-cronjob.yaml @@ -35,7 +35,13 @@ metadata: rules: - apiGroups: [""] resources: ["pods"] - verbs: ["get", "list", "delete"] + # watch is required by `kubectl wait` - without it the wait's internal + # watch retry loop never terminates cleanly even with --timeout set + # (confirmed live 2026-08-18: it just kept retrying past the stated + # 120s timeout). The restore/unseal steps themselves still succeed + # without it - this only affects how gracefully the job detects the + # pod coming back before unsealing. + verbs: ["get", "list", "watch", "delete"] - apiGroups: [""] resources: ["pods/exec"] verbs: ["create"]