railiance-platform/history/2026-09-05-eso-auth-recovery.md

Three failing secret deliveries recovered

User authorized the next operational follow-up after signing activation. RPF-WP-0037 records the bounded recovery; RPF-WP-0036 retains telemetry ownership.

Forgejo mailer, reuse-surface and target-revenue were active consumers. All three stores used static tokens rejected during self-validation. Attended native KV reads and captured Kubernetes reads proved every workload field identical before resync. No application values, tokens, hashes or fingerprints were recorded.

Dedicated namespace/SA/audience Kubernetes bindings replaced static token auth. New policies grant only exact data read and self-token lookup/revocation; 15-minute TTL/max/explicit max and no default policy are enforced. Source was committed and pushed before apply. Existing namespace restrictions were retained and JSON Patch tested live store scope before replacing authentication.

Each lane passed native read, wrong-SA/namespace/audience, sibling/write and TTL checks. Fresh reconciliation timestamps advanced and workload value equality remained true. All three consumers remained ready; no rollout was requested. All 27 ExternalSecrets report Ready/SecretSynced at final verification.

Cleanup initially stopped because native lookup returned 403 with bad token, while the helper expected 400. Fixed classification distinguishes explicit bad token from permission denial; regression tests cover both. Native lookup proved all three predecessors invalid. After checking zero store references, their obsolete Kubernetes Secrets were deleted with UID/resourceVersion preconditions.

Updated deployment manifests, runbook, bootstrap documentation and CCR-2026-0005 delivery binding. Caller-facing policies and catalog route remain separately retained. 187 unit tests and credential validation passed; the signing test fixture now clears active-frontdoor state when constructing an approved draft.

Evidence: docs/evidence/RPF-WP-0037-eso-auth-recovery-2026-09-05.json. No residual delivery repair remains. Backup predecessor invalidation/recovery and OpenBao operator-only access retain their separate WP-0029/WP-0025 gates.