ops-warden/docs/credential-governance-break-glass.md

Credential governance break-glass contract

Status: active design contract for WARDEN-WP-0027-T02. This document does not authorize a seal, re-key, token mint, policy write, workload restart, or host reboot.

Decision boundary

ops-warden consumes and verifies credential-control evidence; it does not own the OpenBao cluster, unseal shares, recovery snapshots, policies, or root token. railiance-platform is accountable for the OpenBao operation. The share custodians, platform driver, abort operator, provider-console operator, and affected workload owners participate through an attended approval window.

The current production trust-root is the rotated Shamir barrier restored to railiance01 in RMASTER-WP-0020: three separately custodied shares with a threshold of two. Share-holder identities and share material remain in the approved out-of-band custody system, never Git, State Hub, shell history, logs, or chat. A readiness receipt names participating roles and attests that two distinct custodians are present; it never contains a share or recovery value.

Root is offline bootstrap/break-glass material only. It is not a substitute for platform-admin OIDC and must not be used through the browser UI. An ordinary unseal uses threshold shares and does not require a root token.

Graded response

Grade	Trigger	Action owner	Exit evidence
Observe	Suspicion without confirmed credential disclosure	lane owner + risk-nexus	Metadata-only taint, audit, policy, and capability review
Soft lockdown	Coding-agent access must stop while human recovery remains available	railiance-platform	agent-high-risk-boundary source/live equality; all concrete high-risk data paths denied; metadata readable
Lane containment	One or more concrete credentials are exposed	each credential owner	Front door disabled, provider/OpenBao rotation through the owner-native procedure, consumer cutover, taint cleared only after verification
Hard lockdown	OpenBao trust or control-plane integrity is in doubt	platform driver under attended approval	Fresh encrypted snapshot receipt, intentional seal, sealed-state proof, 2-of-3 unseal, post-unseal and consumer verification
Re-key	A Shamir share or the barrier custody model is compromised	platform owner + threshold custodians	Separately approved OpenBao re-key ceremony, new threshold custody attestation, old-share retirement, recovery drill

Hard lockdown is not an agent command. The irreversible hold point is the platform owner's attended seal action. All prerequisites below must be true before that hold point; repository access alone grants no authority to cross it.

Route planning must select openbao-shamir-recovery-ceremony and return one founder_required approval act. A result that selects openbao-api-key, asks for paste-once provisioning, or offers any raw-value transport is a routing failure and must not be executed.

Pre-seal hold point

• An approved, bounded window names the accountable platform driver and a distinct abort operator.
• Two distinct Shamir custodians attest availability through the approved out-of-band channel.
• Independent provider-console access is verified by its owner.
• A current Raft snapshot is encrypted and stored off-host; the non-secret receipt binds cluster id, Raft index, plaintext/encrypted hashes, location, age, and verification without including protected material.
• Current OpenBao health, seal state, Raft peers, audit device, auth methods, policy fingerprints, and consumer readiness are captured as metadata.
• A rollback/re-entry order and stop conditions are acknowledged by affected workload owners.

Any missing or stale item aborts before sealing. A live incident may require immediate network isolation, but that does not authorize improvising share or root-token handling.

Re-entry sequence

The platform owner performs the exact commands from railiance-platform/docs/openbao.md; ops-warden does not copy a second execution procedure here.

1. Confirm the instance is intentionally sealed and the approved window is still open.
2. Two custodians supply shares through hidden, non-logged prompts. No agent observes the values.
3. Prove initialized=true and sealed=false, then run the owner post-unseal verification.
4. Verify Raft, persistent audit output, OIDC metadata, SSH roles, and policy fingerprints before restoring normal access.
5. Reconcile ExternalSecret stores and bounded consumers in dependency order.
6. Run value-safe capability probes, including the coding-agent deny-wins check and an ops-warden signing smoke that records only backend and decision ids.
7. Revoke temporary operator tokens and close the window with non-secret timing, status, and abort/rollback evidence.

The August 3 migration already proved two attended restart/unseal cycles under the same 2-of-3 barrier. T02 still requires one current emergency-seal drill against the authoritative runtime because restore rehearsal and intentional production lockdown are different claims.

Warden signing recovery

Do not apply the parked standalone warden-sign AppRole as a T02 break-glass path.

• Normal operation uses the railiance-platform credential broker and short-lived warden-sign child token.
• Broker/issuer recovery uses an attended OIDC platform operation.
• A sealed or integrity-compromised OpenBao is recovered by the Shamir trust-root; another AppRole cannot bypass the seal.
• Placing standing AppRole material outside the broker expands credential custody without improving root recovery.

The AppRole dry-run in SECRETS-WP-0004 remains useful negative evidence: its capability set is narrow. It is not apply authorization. A separately approved ops-bridge unattended-signing design may re-evaluate it under its own workplan; that service-access question is outside T02 and does not create recovery authority.

Evidence and owner surfaces

• Current barrier/re-entry evidence: railiance-master RMASTER-WP-0020 and docs/evidence/openbao-isolated-restore-2026-08-03.json
• Authoritative execution and recovery runbook: railiance-platform/docs/openbao.md
• Current coordinated recovery gates: railiance-platform/docs/railiance01-coordinated-reboot.md
• Emergency evidence contract and validator: railiance-platform/docs/openbao-emergency-drill-evidence.example.json and make openbao-validate-emergency-evidence
• Soft-lockdown policy and proof: railiance-platform RAILIANCE-WP-0022 and ops-warden scripts/check_agent_read_boundary.py
• Warden-sign recovery input: secrets-engine SECRETS-WP-0004 and workplans/ADHOC-2026-08-11.md T03