ops-warden/workplans/WARDEN-WP-0027-credential-governance-lockdown.md
tegwick bfa0eda327
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 2s
Close ADHOC-2026-08-11: hand warden-sign AppRole to WP-0027
T03 stays parked (neither apply nor withdraw). Neither un-park trigger has
fired, so the ad-hoc is finished and WP-0027 T02 owns the question.
2026-08-15 20:35:12 +02:00

6.7 KiB

id type title domain repo status owner topic_slug planning_priority planning_order created updated state_hub_workstream_id
WARDEN-WP-0027 workplan Tamper-resistant credential governance + mass rotation/lockdown (Strand B) infotech ops-warden backlog codex custodian medium 27 2026-07-16 2026-08-15 7d697c52-766a-4562-b2ad-a722880bcdcb

Tamper-resistant credential governance + mass rotation/lockdown (Strand B)

Origin

Explicitly deferred from WARDEN-WP-0026 (credential disclosure hygiene, Strand A). WP-0026 "Out of scope" carves out the heavyweight governance machinery and directs that it be "capture[d] separately if/when justified." This workplan is that capture.

Strand A makes accidental disclosure structurally hard and gives every lane advisory rotation guidance. Strand B is the executable, tamper-resistant layer: turning that advisory guidance into one-command action and hardening policy governance against silent drift or malicious change.

Status: backlog (captured, not scheduled)

Tasks are cancel (deferred with the workplan, not abandoned) so hub consistency C-23 does not force active. On activation: set workplan to ready/active and re-open tasks as todo/progress.

Frontmatter status: backlog as of 2026-07-17 (Strand A / WP-0026 and tenant custody WP-0028 are finished; no activation gate has fired). Tasks remain todo (not wait/progress) so hub consistency C-23 does not force the workplan back to active. This is deliberately not ready. It carries real cost and blast radius (break-glass re-key, trust-root design) that is not justified until a concrete trigger appears. See Activation gate below. Nothing here is implemented until the gate is met and Bernd promotes it to ready (then move tasks todo → progress as work starts).

Activation gate (promote to ready only when ≥1 holds)

  • A real disclosure incident requires rotating more than a couple of secrets at once, making manual per-lane rotation (Strand A) too slow.
  • Fleet policy for OpenBao mandates tamper-evident policy governance or a designed break-glass path.
  • Audit/compliance requires provable "reconcile policy to a known-good commit."

Goal

Make credential response executable and trustworthy at fleet scale: one command rotates or re-establishes a set of tainted secrets; policy changes are tamper-evident and reconcilable to a known-good state; a graded lockdown / break-glass path exists with an explicit trust-root.

Scope boundary (unchanged from Strand A)

ops-warden still custodies no secret values. Strand B orchestrates the owner's tools (OpenBao, provider re-mint, railiance-platform credential broker) as the caller — it does not hold or vend secrets. Rotation execution runs the owner-native path; ops-warden sequences and verifies it.

Task: Executable mass rotation driver

id: WARDEN-WP-0027-T01
status: cancel
priority: high
state_hub_task_id: "604aad14-d398-4c02-85e5-7ff37a905a1b"

Turn Strand A's per-lane rotation: guidance (WP-0026 T06) into an executable driver: warden rotate <id> (single lane) and warden rotate --tainted (all lanes marked EXPOSED per WP-0026 T05). Each step runs the owner-native command (provider re-mint, bao kv put, re-encrypt+reupload for re-establish lanes) as the caller, verifies via capabilities (never reads the value), and clears the exposed_at taint on success. Dry-run first; idempotent; per-lane failure isolates.

Done when: a tainted set of lanes can be rotated/re-established with one command, each verified capabilities-safe, taint cleared only on success.

Depends on: WP-0026 T05 (taint convention), T06 (rotation registry).

Task: Graded lockdown / break-glass with explicit trust-root

id: WARDEN-WP-0027-T02
status: cancel
priority: medium
state_hub_task_id: "9d004d8f-6215-4178-bd13-5785d24fd152"

Design and document a graded lockdown: (a) soft — deny agent roles read on all high-risk lanes; (b) hard — seal + re-key with a pre-designed trust-root and quorum. Define the trust-root (who holds unseal shares, recovery keys), the break-glass invocation, and the re-entry path. Design + runbook first; any executable seal step is opt-in and attended.

Done when: a documented, rehearsed break-glass path exists with a named trust-root and quorum, and soft-lockdown is executable via capabilities-based policy toggles.

Parked input — the warden-sign AppRole (2026-08-11). secrets-engine holds a validated dry-run for a warden-sign AppRole (policy + role, update on ssh/sign/{agt,adm,atm}-role only). It was parked rather than withdrawn specifically because it is an input to this task: today the credential broker is the only autonomous path to a signing token, so if its issuer lapses, recovery is a founder OIDC act. Whether a second autonomous path should exist — and whether it is the AppRole or something this trust-root design supersedes — is a break-glass question, not a routing one. Resolve it here. Context and the counter-argument (AppRole is narrower in capability than placing the broker's issuer token on a remote host) are in workplans/ADHOC-2026-08-11.md T03 (ad-hoc finished 2026-08-15; question lives here now); secrets-engine was told to stop holding apply readiness until this task or the ops-bridge cutover fires (msg 863c7b57).

Task: Tamper-evident policy governance + reconcile

id: WARDEN-WP-0027-T03
status: cancel
priority: medium
state_hub_task_id: "94d5dcaf-abf0-417c-a6ef-26e8c50905a8"

Policy-as-code for OpenBao policies/roles with tamper-evidence: a signed/hashed manifest of the intended policy set, drift detection against live OpenBao, and a reconcile-to-known-good-commit path. (Drift detection may land independently even if full reconcile stays gated.) Coordinate ownership with railiance-platform (OpenBao deployment) — ops-warden contributes the ops-access policy surface, not the cluster.

Done when: live OpenBao policy state is diffable against a signed known-good manifest, and an attended reconcile can restore it.

Cross-repo: railiance-platform (OpenBao cluster + policy custody).

References

  • WARDEN-WP-0026 — Strand A (disclosure hygiene, advisory rotation) — prerequisite
  • .claude/rules/credential-routing.md — ops-warden custodies no secret values
  • railiance-platform — OpenBao cluster, policy custody, credential broker
  • wiki/AccessRouting.md — issue vs route vs assist boundary
  • workplans/ADHOC-2026-08-11.md T03 — parked warden-sign AppRole (ad-hoc finished 2026-08-15); un-parks on this workplan's break-glass task or the ops-bridge cert_command cutover
  • secrets-engine SECRETS-WP-0004 — the parked AppRole apply/handoff