Record the ESO store recovery and the warden login findings.
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
CI Smoke / container-smoke (push) Successful in 3s

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
codex 2026-09-21 19:41:06 +02:00
parent c635b381ef
commit f2ca7fb883

View file

@ -209,3 +209,17 @@ All of the following were done with the founder's go-ahead, in `ADMINISTER @ rea
**RPF-WP-0045.** The runbook for moving openbao-activity-core and openbao-email-connect to OpenBao Kubernetes auth, as the three recovered stores already use, is written. Nothing is applied. One step needs the OpenBao admin credential and is the founder's to run.
**Credential exposure (routed to railiance-platform).** Secrets created with `kubectl apply` carry their full data in the `kubectl.kubernetes.io/last-applied-configuration` annotation, so a *metadata-only* read prints the secret. This was observed on the two dead ESO tokens. It is suspected, not verified, on five live `*-eso-token` Secrets. The custodian did not inspect them. Remediation — a check that prints no value, stripping the annotation, deciding on rotation, and fixing the creation paths — belongs to custody.
## ESO stores recovered, 2026-09-21 (RPF-WP-0045 T01T04)
`openbao-activity-core` and `openbao-email-connect` were moved off their dead static tokens to OpenBao Kubernetes auth. Each role is bound to one ServiceAccount in one namespace, issues 15-minute tokens, and carries a single policy scoped to exactly the paths its ExternalSecrets read. The founder's go-ahead covered T01, T03 and T04.
**T01** was run through `warden access openbao-platform-admin-login --exec`. It took four more attempts to succeed:
1. The child's output made warden fail closed; the lane requires a silent child.
2. `BAO_ADDR` pointed at an unreachable public name; the operator path is the tunnel at `127.0.0.1:18200`.
3. WSL had no browser opener; fixed with a `~/.local/bin/xdg-open` shim to `explorer.exe`.
4. The fifth run succeeded, but warden reported the session revocation "could not be confirmed". It also exits 0 on a failed login and audits every attempt as `ok`.
These are sent to ops-warden as one improvement suggestion (`6a1ce1bb`). The undeclared platform-admin role and policy, and the suspected missing `revoke-self` capability, are sent to railiance-platform (`641673a4`).
**Result:** both stores are Ready, the five stalled ExternalSecrets synced at 17:39Z (activity-core's offsite-backup credential among them), and **37/37 ExternalSecrets are ready cluster-wide**. The two dead token Secrets are deleted in T06, after 24 hours of clean syncs.