tegwick
bfa0eda327
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.
149 lines
6.7 KiB
Markdown
149 lines
6.7 KiB
Markdown
---
|
|
id: WARDEN-WP-0027
|
|
type: workplan
|
|
title: "Tamper-resistant credential governance + mass rotation/lockdown (Strand B)"
|
|
domain: infotech
|
|
repo: ops-warden
|
|
status: backlog
|
|
owner: codex
|
|
topic_slug: custodian
|
|
planning_priority: medium
|
|
planning_order: 27
|
|
created: "2026-07-16"
|
|
updated: "2026-08-15"
|
|
state_hub_workstream_id: "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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|