coulomb/ops-warden
4
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions
ops-warden/wiki/playbooks/openbao-shamir-recovery-ceremony.md
tegwick e3b9b1620c fix: route OpenBao recovery ceremonies safely 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0290b-3241-74c3-b868-6049545af836
2026-08-22 20:54:45 +02:00

1.6 KiB
Raw Blame History

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:

    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.