# Workload Security Posture — NetKingdom standard (draft)

> **Status:** ops-warden-authored draft, WARDEN-WP-0015 T1. **Pending promotion to
> canon** along two homes (see *Canon layering*). Until landed, this file is the
> authoritative working draft; the canon copies supersede it once merged.
>
> **ops-warden's role:** *author + conformance*. ops-warden does **not** enforce this
> standard at runtime (flex-auth) and does **not** hold the secrets (OpenBao). It
> authors the ops-security slice and ships conformance checks + dev-tier doubles.

NetKingdom IT-security posture is defined along **two orthogonal axes**. A workload's
right to receive a secret depends on **both**, unified by a secret-flow lattice.

---

## Axis A — Environment posture (how the secret store is secured)

The lifecycle tier of the *secret store backing a workload*. Contracts are identical at
every tier (so automation and the `warden access` proxy run unchanged); only the
backend's security posture changes.

**R1 — Contract parity, posture divergence.** Identical interface at every tier; only
posture changes. This is why dev-tier contract doubles ("fake bao") 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) stay quarantined in test.
**R3 — Dev touches no real data, ever.** An insecure personal mock store in dev is
sanctioned *iff* dev uses only synthetic data. Absolute invariant.
**R4 — Phase-changes are ceremonies, not copies.** `test → prod` is a gated checklist
(regenerate secrets, switch unseal model, enable break-glass, human sign-off),
referencing the existing net-kingdom `security-bootstrap-*` and unseal-custody docs —
not duplicating them.

| | 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 (how trusted a workload is)

**Production is a posture, not a maturity.** A workload can run in prod posture yet be
low maturity (alpha with friendly customers). Maturity gates *which secrets and data
classes* a prod workload may touch. Levels are a total order `M0 < M1 < M2 < M3`.

| Level | Phase | Max `DataClassification` it may handle | Promotion gate (into this level) |
| --- | --- | --- | --- |
| **M0** | Experimental / PoC | synthetic only | — (entry level) |
| **M1** | Alpha / early-access | low-criticality, loss-acceptable; **no** `confidential`/`restricted` | friendly-customer scope agreed, 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 ops, compliance audit |

`DataClassification` (`confidential`, `restricted`, …) is **reused** from the
info-tech-canon Data Model — not redefined here. Promotion gates **reuse** the
info-tech-canon DevSecOps Model's quality/policy gates and `DeploymentVerification`
(SLOs / smoke / canary / operator confirmation), applied to maturity advancement.

---

## The combined rule — secret-flow lattice

A secret carries a `required_maturity` (and implicitly the `required_maturity` of its
`DataClassification`). Delivery is **no-write-down**:

```
deliver(secret → workload) is permitted only if
    workload.env_posture == prod                                 # Axis A
AND workload.maturity     >= secret.required_maturity             # Axis B
AND workload.maturity     >= required_maturity(dataclass(secret)) # data class floor
```

**"Critical-infrastructure secrets must not be transferred to workloads below maturity
M"** is exactly the second clause. The lattice is **checkable** by ops-warden
(conformance) and **enforceable** at runtime by flex-auth. Access *semantics* (who, on
behalf of whom) remain governed by the CARING Access Governance Standard.

Worked example: an `NPM_AUTH_TOKEN` used only by a build pipeline → `required_maturity:
M1`, dataclass `internal`. A production database password for regulated user data →
`required_maturity: M3`, dataclass `restricted`; it may be delivered only to a
prod-posture, M3 workload.

---

## Canon layering (where each part lands)

| Part | Canonical home | ops-warden role |
| --- | --- | --- |
| Generic `WorkloadMaturityLevel` concept + the secret-flow lattice | **info-tech-canon** (DevSecOps / Landscape; reuses Data Model `DataClassification`, Security Model criticality) | Contribute; do not fork |
| NetKingdom M0–M3 security **requirements** + env-posture ceremonies | **net-kingdom canon** (beside `openbao-unseal-custody-models.md`, `responsibility-map.md`) | Author the ops-security slice |
| Machine-readable descriptors + conformance checker + dev doubles | **ops-warden** (`registry/policy/`, `scripts/`) | Own (WP-0015 T2–T4) |
| Runtime enforcement of the lattice | **flex-auth** | Route; do not enforce here |

---

## Boundaries preserved

- **OpenBao** holds secret values. ops-warden never custodies them.
- **flex-auth** decides allow/deny (incl. enforcing this lattice at runtime).
- **CARING / Access Control** governs access semantics and delegation.
- **key-cape** establishes identity. ops-warden authors the standard and *checks
  conformance* — it does not become a broker, PDP, or IdP (responsibility-map).

---

## See also

- `wiki/OperatorAccessAssist.md` — the posture-aware `warden access` fetch surface
- `net-kingdom/docs/openbao-unseal-custody-models.md`, `responsibility-map.md`,
  `platform-root-custody.md`, `security-bootstrap-*`
- info-tech-canon: Security Model, DevSecOps Model, Data Model, CARING Access Governance
- `workplans/WARDEN-WP-0015-secret-lifecycle-tiering.md`