coulomb/ops-warden
4
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions

fix: route OpenBao recovery ceremonies safely

Browse source 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0290b-3241-74c3-b868-6049545af836
This commit is contained in:
tegwick 2026-08-22 20:54:45 +02:00
parent fff76ef089
commit e3b9b1620c
10 changed files with 131 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

1
wiki/CredentialRouting.md
View file

@ -91,6 +91,7 @@ lists the interim set — WARDEN-WP-0030).
| `ops-warden-warden-sign-token` | "railiance-platform broker owns the `warden-sign` lease — use `credential exec`" | `railiance-platform/scripts/credential.py exec --grant ops-warden/warden-sign` (see playbook) |
| `openbao-api-key` | "OpenBao owns this — here is the path/command shape" | Call OpenBao directly, or use `warden access --fetch/--exec` as yourself when the lane is `exec_capable` |
| `openbao-platform-admin-login` | "This is an attended OpenBao administration identity act, not workload secret retrieval" | Use KeyCape-backed OIDC/MFA at `auth/netkingdom`, role `platform-admin`; never substitute a workload role or root token |
| `openbao-shamir-recovery-ceremony` | "This is an attended trust-root ceremony, not secret provisioning" | Obtain one explicit approval and follow the railiance-platform recovery checklist with the existing out-of-band custodians; never send shares through Warden |
| `flex-auth-policy-check` | "flex-auth decides — here is the policy doc" | Query flex-auth / embed the PEP |
| `key-cape-oidc-login` | "key-cape / Keycloak owns identity" | Authenticate via IAM Profile, or use the `warden access` login lane as yourself |
| `ops-bridge-tunnel` | "ops-bridge owns transport — supply a `cert_command`" | Open the tunnel with ops-bridge |

37
wiki/playbooks/openbao-shamir-recovery-ceremony.md Normal file
View file

@ -0,0 +1,37 @@
# OpenBao Shamir recovery ceremony
This lane routes an attended production seal/unseal or trust-root recovery need
to `railiance-platform`. It does not retrieve, provision, proxy, or transport an
unseal share, recovery value, OpenBao token, snapshot, or console credential.
## Worker checklist
1. Plan the need before drafting an operator step:
```bash
warden plan "attended OpenBao Shamir emergency seal/unseal recovery ceremony" --json
```
The result must select `openbao-shamir-recovery-ceremony`, return
`founder_required`, and name one `approve` act. If it selects
`openbao-api-key`, proposes paste-once provisioning, or requests a raw share,
stop without executing the proposed act.
2. Treat approval as coordination, not secret delivery. The platform owner uses
the existing out-of-band share custody and provider-console paths. Warden
Desk must never receive a share or console credential.
3. Follow the authoritative owner checklist in
`railiance-platform/docs/railiance01-coordinated-reboot.md` and the OpenBao
recovery section of `railiance-platform/docs/openbao.md`. The local consumer
boundary and evidence requirements are in
`docs/credential-governance-break-glass.md`.
4. Stop before the live hold point unless the owner preflight reports
`ready_for_live_execution: true` and the operator gives an explicit go/no-go
for that bounded window.
Allowed records are non-secret approval ids, role attestations, timestamps,
seal-state booleans, hashes, and verification outcomes. Never place shares,
tokens, credentials, Secret data, or decrypted snapshots in Git, State Hub,
logs, shell history, or chat.