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

id, type, title, domain, repo, status, owner, topic_slug, planning_priority, planning_order, created, updated, state_hub_workstream_id

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	planning_order	created	updated	state_hub_workstream_id
WARDEN-WP-0015	workplan	Workload Security Posture — env posture × maturity + conformance	infotech	ops-warden	finished	codex	custodian	high	15	2026-06-27	2026-06-27	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)

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

• 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.
• 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.
• 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).
• 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)

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

• 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.
• 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).
• warden policy list|show lookup (mirrors warden route; --json).
• Tests: tests/test_posture.py (load, lattice allow/deny matrix, validation rejections, CLI). 184 pass, lint clean.

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

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

• 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.
• Surfaces conformance + lattice violations; never reads or prints a secret value (manifest is metadata-only). Example: examples/posture-conformance.example.yaml.
• 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

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

• 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.
• Documented the pattern in the standard (R1) as the sanctioned dev backend.
• 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

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

• 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.
• SCOPE: add the posture policy + conformance surface; note the net-kingdom / info-tech-canon homes; bump the maturity vector where warranted.
• 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.
• 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)