ops-warden/workplans/archived/260627-WARDEN-WP-0015-secret-lifecycle-tiering.md

---
id: WARDEN-WP-0015
type: workplan
title: "Workload Security Posture — env posture × maturity + conformance"
domain: infotech
repo: ops-warden
status: finished
owner: codex
topic_slug: custodian
planning_priority: high
planning_order: 15
created: "2026-06-27"
updated: "2026-06-27"
state_hub_workstream_id: "99f4a0e1-853c-456f-8aa7-8ff0f318ea65"
---

# WARDEN-WP-0015 — Workload Security Posture (two-axis) + conformance

**Scope:** Establish a NetKingdom standard for IT-security posture across **two
orthogonal axes**, and make ops-warden the **conformance steward** for it:

- **Axis A — Environment posture** (`dev → test → prod`): how the *secret store* is
  secured (mock / OpenBao `-dev` / sealed). Identical contracts, divergent posture.
- **Axis B — Workload maturity** (`M0 → M3`): how *trusted* a workload is to receive
  secrets and handle classified data (PoC → alpha/early-access → beta/GA → critical).

The axes combine in a **secret-flow lattice**: a secret may be delivered to a workload
only if the workload's posture *and* maturity meet the secret's requirements. ops-warden
authors the ops-security slice, ships machine-readable descriptors + a conformance
checker (incl. the lattice check), and the dev-tier **contract-double** fixture library
(the "fake bao" pattern generalized).

**Decisions locked (2026-06-27):**
- Two-axis model folded into this WP (was "Secret Lifecycle Tiering", env posture only).
- Authoritative **NetKingdom requirements** (M0–M3 table, secret-flow gates, env-posture
  ceremonies) live in **net-kingdom canon**; the **generic `WorkloadMaturityLevel`
  concept + lattice** is contributed to **info-tech-canon** (DevSecOps/Landscape),
  reusing its governed `DataClassification`. ops-warden authors the ops-security slice +
  conformance tooling.
- ops-warden role = **author + conformance checks**, **not** runtime enforcement.

**Reuse, don't reinvent (info-tech-canon already defines the primitives):**
`DataClassification` (`confidential`/`restricted`…) in the Data Model; promotion /
quality gates / policy gates / `DeploymentVerification` + progressive delivery in the
DevSecOps Model; asset/business **criticality** in the Security Model; access semantics
in the CARING Access Governance Standard. This WP **assembles** these into a named
maturity ladder + flow rule; it does not fork them.

**Hard boundary (responsibility-map, ~line 154):** ops-warden "must not become a
universal secret broker — runtime secrets remain OpenBao; authorization remains
flex-auth." ops-warden = policy author + conformance verifier only. OpenBao holds the
secrets; flex-auth makes allow/deny decisions; CARING governs access semantics.

**Cross-repo note:** T1/T5 author content destined for **net-kingdom** and
**info-tech-canon**. ops-warden drafts; landing it is coordinated through each repo's
own process (inbox/PR), not a unilateral write from here.

**Depends on / relates to:** WARDEN-WP-0014 (the `warden access` proxy is the
posture-aware fetch surface; its caller-identity/transit guardrails are prod-compatible).

**Status:** `finished` — all five tasks done. T1 authored the standard, T2 shipped the
descriptors + `warden policy`, T3 the read-only conformance checker, T4 the dev-double
library, T5 the INTENT/SCOPE alignment. Canon landing in net-kingdom / info-tech-canon
is owner-driven and tracked via the open coordination messages (not closed here).

---

## The model (to be encoded by this WP)

### Axis A — Environment posture (the secret store)

**R1 — Contract parity, posture divergence.** Identical interface at every tier; only
the backend's security posture changes. Automation written once runs at all tiers
unchanged (this is why contract doubles work).
**R2 — Promote topology, regenerate material.** Secret *values* are never promoted up
the ladder; only *structure* (paths, policy shape, names). Values are generated fresh
per tier. Test conveniences (reuse, single-unseal) are quarantined in test.
**R3 — Dev touches no real data, ever.** Insecure personal mock store is sanctioned
*iff* dev uses only synthetic data. Absolute.
**R4 — Phase-changes are ceremonies, not copies.** test→prod is a gated checklist
referencing net-kingdom `security-bootstrap-*` / unseal-custody docs.

| | dev | test | prod |
| --- | --- | --- | --- |
| backend | mock / contract double | OpenBao `-dev` (single-unseal) | OpenBao sealed (Shamir 3-of-5) |
| real values | forbidden (synthetic) | generated, reuse allowed | generated fresh, reuse forbidden |
| unseal | n/a | single key / auto | 3-of-5 + break-glass |
| real user/business data | never | never | allowed |
| audit | optional | on | full, tamper-evident |

### Axis B — Workload maturity (the trust to receive secrets/data)

**Production is a posture, not a maturity.** A workload can be prod-posture yet low
maturity (alpha with friendly customers). Maturity gates *which secrets and data
classes* a prod workload may touch.

| Level | Phase | Max DataClassification | Promotion gate (reuses DevSecOps gates) |
| --- | --- | --- | --- |
| **M0** | Experimental / PoC | synthetic only | — |
| **M1** | Alpha / early-access | low-criticality, loss-acceptable; no confidential/restricted | friendly-customer scope, basic SLO, data-handling note |
| **M2** | Beta / GA | up to `confidential`; SLOs; audited | security review, SLO history, on-call, incident runbooks |
| **M3** | Critical / regulated | `restricted`; break-glass; compliance | pen-test, 3-of-5 custody, human-in-loop, compliance audit |

### The combined rule (secret-flow lattice)

```
deliver(secret → workload) permitted only if
    workload.env_posture == prod                       # Axis A
AND workload.maturity     >= secret.required_maturity   # Axis B (no-write-down)
AND workload.maturity     >= required_maturity(dataclass(secret))
```

"Critical secrets must not be transferred to workloads below maturity M" is exactly
this no-write-down constraint. Checkable by ops-warden; enforceable by flex-auth.

---

## Tasks

### T1 — Author the two-axis Workload Security Posture standard (canon-bound)

```task
id: WARDEN-WP-0015-T01
status: done
priority: high
state_hub_task_id: "85aeb676-a593-4056-986a-db14d4c5209f"
```

- [x] Drafted the standard: Axis A (R1–R4 + env-posture matrix + phase-change ceremonies)
      and Axis B (M0–M3 ladder + promotion gates) unified by the secret-flow lattice —
      `wiki/WorkloadSecurityPosture.md`.
- [x] Layered it: doc marks the generic `WorkloadMaturityLevel` + lattice → **info-tech-canon**
      (reusing `DataClassification`) and the NetKingdom M0–M3 requirements + env-posture
      ceremonies → **net-kingdom canon**, with a canon-layering table.
- [x] Cross-linked the unseal/bootstrap/responsibility canon + info-tech-canon
      Security/DevSecOps/Data/CARING models. Staged in ops-warden; **coordination
      opened** to net-kingdom (msg 8d6f8d83) and info-tech-canon (msg ca07b085).
- [x] Encoded ops-warden's role: author + conformance, not enforcement/custody.
- Note: canon **landing** in the two repos is owner-driven; tracked to closure in T5.

### T2 — Machine-readable posture descriptors (both axes)

```task
id: WARDEN-WP-0015-T02
status: done
priority: high
state_hub_task_id: "011fb0af-154d-40f4-a03e-3172c325321a"
```

- [x] `registry/policy/security-posture.yaml` — env-posture tiers (backend, value-policy,
      unseal, data-class, audit) **and** maturity levels (M0–M3, max DataClassification,
      promotion gates), `dataclass_floor` mapping, and the lattice rule. No secret material.
- [x] Loader + validation in `src/warden/posture.py` (mirrors `routing/catalog.py`):
      unique/contiguous ranks, dataclass_floor references known levels, lattice env
      posture exists. Includes the pure `can_deliver` lattice helper (reused by T3).
- [x] `warden policy list|show` lookup (mirrors `warden route`; `--json`).
- [x] Tests: `tests/test_posture.py` (load, lattice allow/deny matrix, validation
      rejections, CLI). 184 pass, lint clean.

### T3 — Conformance checker (incl. secret-flow lattice)

```task
id: WARDEN-WP-0015-T03
status: done
priority: high
state_hub_task_id: "c1a0e987-19d0-478e-ac08-2dbe98e64e09"
```

- [x] `scripts/check_secret_posture_conformance.py` — asserts env-posture matches the
      standard (`backend`/`unseal`/`real_values` per tier) **and** evaluates the lattice
      via `posture.can_deliver`: flags any secret whose `required_maturity` or data-class
      floor exceeds a target workload's maturity, or that targets a non-prod workload.
      Drift-style report, like `check_principals_drift.py`. Read-only; exit 0/1/2.
- [x] Surfaces conformance + lattice violations; never reads or prints a secret value
      (manifest is metadata-only). Example: `examples/posture-conformance.example.yaml`.
- [x] Tests: `tests/test_posture_conformance.py` (env mismatch, unknown env, lattice
      deny/allow, missing workload, exit codes). 8 cases, lint clean.

### T4 — Dev-tier contract-double fixture library

```task
id: WARDEN-WP-0015-T04
status: done
priority: medium
state_hub_task_id: "e556fd2e-4e39-4c7d-bd94-b4330e4bef45"
```

- [x] Generalized "fake bao" into `src/warden/doubles.py`: `materialize_doubles()`
      writes hermetic dev-tier doubles for routed subsystems (`bao`, `key-cape`)
      honoring each contract (argv/stdout/exit), emitting **synthetic values only**
      (`synthetic-` prefix, asserted in tests). `doubles_path_prepended()` puts them
      ahead on PATH for fully offline dev/test of access flows.
- [x] Documented the pattern in the standard (R1) as the sanctioned `dev` backend.
- [x] Tests: `tests/test_doubles.py` (contract honoring, synthetic-only, unknown
      contract → exit 2, end-to-end proxy fetch offline against the double). 9 cases.

### T5 — INTENT/SCOPE alignment + canon contributions

```task
id: WARDEN-WP-0015-T05
status: done
priority: medium
state_hub_task_id: "298c9b09-4a5a-41bf-a3bd-6c572385236b"
```

- [x] `INTENT.md`: ops-warden stewards **security-policy conformance** of the
      infrastructure (authoring the two-axis posture standard + conformance checks + dev
      doubles), scoped to author+check — **not** enforcement or custody.
- [x] SCOPE: add the posture policy + conformance surface; note the net-kingdom /
      info-tech-canon homes; bump the maturity vector where warranted.
- [x] Canon landing tracked to a documented hand-off. The contributions are **drafted
      and offered**: info-tech-canon (generic `WorkloadMaturityLevel` + lattice, msg
      `ca07b085`) and net-kingdom (M0–M3 requirements + env-posture ceremonies, msg
      `8d6f8d83`). **Landing is owner-driven and out of ops-warden's control** — it is
      tracked through each repo's own inbox/PR process, not closed unilaterally here.
      ops-warden's authored slice + conformance tooling are complete.
- [x] `history/2026-06-27-workload-security-posture-charter.md` — decision record.

2026-06-27 progress: shipped the T3 conformance checker and T4 dev-double library
with tests (200 passing, lint clean); updated `INTENT.md` / `SCOPE.md` /
`wiki/WorkloadSecurityPosture.md` for the author+conformance role. Canon landing in
net-kingdom / info-tech-canon remains owner-driven via the open coordination messages.

---

## Acceptance

- A coherent two-axis standard exists: generic concept in info-tech-canon, NetKingdom
  M0–M3 + env-posture requirements in net-kingdom canon, authored by ops-warden.
- ops-warden ships posture descriptors + a read-only conformance checker (incl. the
  secret-flow lattice) + dev-tier doubles.
- No secret material in any descriptor, checker, fixture, doc, or log.
- ops-warden's role is documented as author+conformance; OpenBao custody, flex-auth
  authorization, and CARING access boundaries are explicitly preserved.
- INTENT/SCOPE reflect the conformance-steward role without overclaiming enforcement.

---

## See also

- `WARDEN-WP-0014` (operator access assist; the posture-aware fetch surface)
- `net-kingdom/docs/openbao-unseal-custody-models.md`, `responsibility-map.md`,
  `platform-root-custody.md`, `security-bootstrap-*`
- `info-tech-canon` Security / DevSecOps / Data Models + CARING Access Governance
- `flex-auth` (runtime enforcement of the lattice, as a follow-up)