Record the ESO store recovery and the warden login findings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
c635b381ef
commit
f2ca7fb883
1 changed files with 14 additions and 0 deletions
|
|
@ -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 T01–T04)
|
||||
|
||||
`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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue