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 todoprogress 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