From 337484ae169bb2d0a241e9593d04d72328bd2ebb Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 22 Aug 2026 14:42:52 +0200 Subject: [PATCH] docs(canon): publish security zones v0.1 Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a0291a-1e87-7151-9934-fcbfe3f65eb1 --- canon/standards/security-zones_v0.1.md | 336 +++++++++++++++++++++++++ 1 file changed, 336 insertions(+) create mode 100644 canon/standards/security-zones_v0.1.md diff --git a/canon/standards/security-zones_v0.1.md b/canon/standards/security-zones_v0.1.md new file mode 100644 index 0000000..8b5a5dd --- /dev/null +++ b/canon/standards/security-zones_v0.1.md @@ -0,0 +1,336 @@ +--- +id: security-zones_v0.1 +type: standard +status: proposed +owner: zone-engine +publication_owner: net-kingdom +date: "2026-08-22" +--- + +# NetKingdom Security Zones v0.1 + +## 1. Purpose + +A security zone is a named workload-admission standard. It answers which +scrutiny a workload has qualified for; control-owner policy then answers what a +particular control does in that zone. A zone is not a repository label, a +credential lane, a network segment, a reef, or a temporary exception. + +This standard is a sibling of `tenancy-posture_v0.1`. It owns zone identity, +membership, admission, resolution, and the time-boxed exception lifecycle. +`flex-auth` remains the only PDP for decisions it renders. Every other control +continues to be owned and evaluated at its existing enforcement point. + +## 2. Authority and conformance + +Authority is split deliberately: + +| Fact or rule | Authority | +| --- | --- | +| Workload identity and requested membership | Workload's responsible repo | +| Zone identities and admission standards | This standard, owned by zone-engine | +| Per-zone stance | Owner of the control that renders the effect | +| Failure behavior when a dependency is unavailable | Owner of the PEP | +| Publication | net-kingdom canon | + +Conformance is **accuracy, not altitude**. A lower zone declared with evidence +is conformant. A stricter zone that the workload cannot evidence is not. +Changing membership to evade a control is not an exception mechanism. + +The workload is the sole **zone** policy subject. It includes independently +governed application, automation, maintenance, and operational/control-plane +execution units. The workload executing a tunnel, credential broker, policy +service, or maintenance operation requires identity; the tunnel, grant, lane, +pattern, action, human, or agent does not become a workload merely because a +control observes it. Those retain native typed identity and caller/resource +context. + +## 3. Resolution is authoritative + +The stable `workload_identity.name` is the join key. Runtime principals, +resources, credential lanes, and controls reference it explicitly. A resolver +MUST NOT infer membership from repository ownership, paths, lane types, actor +classes, environment, criticality, reefs, organization posture, or naming +conventions. + +For a managed deployable, the authoritative cross-repository reference is the +Repo Manager v1 tuple `(rapp_id, workload_identity.name)`, optionally narrowed +by `deployable`. A catalog also declares whether its subject is workload +applicable. Resolution returns both the reference result and admission result: + +- `satisfied` — the workload has an authoritative identity and evidence meeting + the declared zone's floor; `effective_zone` is the declared zone; +- `unsatisfied` — identity and membership are declared, but evidence is below + the admission floor; `effective_zone` is `unknown`; +- `unknown` — identity, membership, or a required floor/evidence input cannot be + resolved for a workload-applicable subject; `effective_zone` is `unknown`; +- `not-applicable` — the owning catalog explicitly establishes that the subject + is an action, actor, lane, pattern, or resource rather than a workload; no + zone is resolved and the control uses that subject's native identity. + +`unknown` is a result, not a zone. A control MUST declare an explicit treatment +for it. That treatment may deny, escalate, or use a reviewed build-stage rule; +it never manufactures membership and never grants an exception. + +## 4. Zone catalog + +The initial catalog follows the estate's existing `M0`–`M3` maturity ladder and +adds one non-monotone continuity band required by ops-warden `ADR-0006`. + +| Zone id | Admission floor | Environment/data boundary | Purpose | +| --- | --- | --- | --- | +| `z0-experimental` | `M0` promotion evidence | Synthetic only; no real credential or user data | Experiments where advisory controls preserve iteration speed | +| `z1-operational` | `M1` promotion evidence | Production secret handling for at most `internal` data | Early operational workloads with an owned front door | +| `z2-protected` | `M2` promotion evidence | `prod`; at most `confidential` data | Production workloads requiring review, SLO/on-call, and incident readiness | +| `z3-critical` | `M3` promotion evidence | `prod`; at most `restricted` data | Critical or regulated workloads with the strongest normal failure behavior | +| `z2-continuity` | `M2` plus dependency/recovery evidence | `prod`; at most `confidential` data | Foundational access or recovery workloads where fail-closed dependency cycles would cause an outage | + +`z2-continuity` is a sibling of `z2-protected`, not a relaxation of its +admission floor. It exists +because enforcement stance is not monotone: a tunnel or credential-issuance +path can require production scrutiny while deliberately remaining fail-open for one +availability-sensitive control. Placement on a reef is never evidence for any +zone. + +### 4.1 Context floor + +The declared zone must be at least as strict as the workload context requires. +The context floor is the maximum of every resolved input: + +| `criticality` | Minimum maturity | +| --- | --- | +| `low` | `M0` | +| `medium` | `M1` | +| `high` | `M2` | +| `critical` | `M3` | + +Data-class floors are consumed from the canon-owned classification mapping; the +current `synthetic → M0`, `internal → M1`, `confidential → M2`, and +`restricted → M3` mapping is already used by ops-warden. An absent or unresolved +floor makes admission `unknown`. In particular, `public` is disclosure policy +and `synthetic` is data origin: they are not aliases, and this standard does not +invent a floor while info-tech-canon's ruling is pending. + +`organization_posture` may select a versioned control profile, but it never +changes identity, membership, or admission. + +## 5. Stance and failure-mode model + +Every owner-qualified control publishes a total mapping over all zone ids plus +`unknown`. There is no implicit default. + +- `enforced` — the control's deny or escalation effect changes the outcome; +- `advisory` — the control evaluates fully and records the outcome it would + have produced, but does not block; +- `exempt` — the control is deliberately not evaluated for this zone and emits + the versioned exemption reason. + +Failure mode is separate and PEP-side: + +- `fail_closed` — an unavailable or invalid evaluator produces the control's + safe blocking/escalation outcome; +- `fail_open` — the PEP proceeds and records that the control was unavailable. + +`exempt` has no failure mode. A local control with no remote dependency uses +`fail_closed` to describe evaluator errors. Changing stance is a policy-package +change owned by the control owner, not a membership change. + +### 5.1 Initial build-stage control profile + +This profile is the v0.1 proposal for the first consumer. It is not stored in a +workload's `zones:` declaration. flex-auth owns the pre-sign rows; ops-warden +owns the other rows and every PEP failure mode. + +| Zone | flex-auth pre-sign stance / ops-warden PEP | agent high-risk read boundary | `warden plan` zone rule | +| --- | --- | --- | --- | +| `z0-experimental` | `advisory` / `fail_open` | `enforced` / `fail_closed` | `advisory`; evaluator failure cannot produce `autonomous` | +| `z1-operational` | `advisory` / `fail_open` | `enforced` / `fail_closed` | `advisory`; evaluator failure cannot produce `autonomous` | +| `z2-protected` | `enforced` / `fail_open` | `enforced` / `fail_closed` | `enforced`; minimum `founder_required` when the zone rule matches | +| `z3-critical` | `enforced` / `fail_closed` | `enforced` / `fail_closed` | `enforced`; minimum `founder_required` when the zone rule matches | +| `z2-continuity` | `enforced` / `fail_open` | `enforced` / `fail_closed` | `enforced`; minimum `founder_required` when the zone rule matches | +| `unknown` | `advisory` / `fail_open` under the versioned `build` profile | `enforced` / `fail_closed` | `enforced`; never `autonomous` from zone evidence | + +The `unknown` pre-sign treatment is an explicit organization-build policy, not +a permissive membership default. It must change through a versioned control +profile when the organization posture graduates. + +The agent read boundary stays enforced in every zone: build-stage permissiveness +does not extend to disclosing high-risk credentials. For a missing lane risk: + +- `z0-experimental` may resolve to `standard` only when admission proves the + lane can expose synthetic material exclusively; +- `z1-operational` and `z2-protected` resolve to at least `high`; +- `z3-critical` resolves to `critical`, treated by the + boundary as at least `high`; and +- unresolved membership resolves to at least `high`. + +An explicit grade always remains preferable. `accepted` is an acceptance record, +not a risk grade. + +## 6. Declaration in `tenancy.yaml` + +For a single-service declaration, `zones:` is a sibling of `tenancy:` and +`workload_identity`. For a `services:` declaration, both `workload_identity` and +`zones` occur inside the same service entry. A multi-service file MUST NOT use a +top-level `zones:` block. + +Every managed running deployable has an authoritative +`rapp-*/declarations/rapp.yaml`. Its `workload_identity.declaration_ref` points +to that declaration, and consuming catalogs reference it using the Repo Manager +v1 tuple. A pre-rapp deployable is migration debt and resolves `unknown`. An +independently governed operational execution unit that is not a managed +deployable may declare directly in its responsible repo's `tenancy.yaml`; this +does not turn a human action or infrastructure resource into a fictional rapp or +workload. + +```yaml +schema_version: "0.1" +framework: netkingdom-tenancy-posture +service: ops-bridge-tunnel +role: operational-access-path +workload_identity: + name: ops-bridge-tunnel + kind: operational-control-plane + responsible_repo: ops-bridge + identity_bindings: + - scheme: ssh-certificate + authority: ops-warden + subject: agt-ops-bridge + principal_type: agent + environment: prod +tenancy: + # tenancy-posture_v0.1 content omitted +zones: + standard: security-zones_v0.1 + membership: z2-continuity + responsible_party: ops-bridge + justification: foundational tunnel path must retain availability under PDP loss + context: + maturity: M2 + criticality: high + data_classification: confidential + evidence: + - ref: docs/evidence/ops-bridge-tunnel-zone.md + supports: [M2, continuity-dependency, recovery] + reviewed: "2026-08-22" + review_due: "2026-11-22" +``` + +The `zones:` block contains only membership evidence. It MUST NOT contain +control stance, failure mode, organization posture, or exceptions. + +Required fields are: + +- `standard` — exactly `security-zones_v0.1`; +- `membership` — one zone id from §4; +- `responsible_party` — the party answering for this membership; +- `justification` — why the zone fits the workload's actual context; +- `context` — the evidenced `maturity`, `criticality`, and + `data_classification` used for admission. A managed workload's latter two + values must agree with its resolved rapp projection; `n/a` requires an + evidence-backed reason; +- `evidence` — one or more references and the admission facts each supports; +- `reviewed` and `review_due` — ISO dates, with review due after review. + +Permanent membership changes are reviewed source changes. A change to a lower +floor also records its reason and approver in the change review. Temporary +relaxation uses an exception and never changes `membership`. + +## 7. Compilation and resolved view + +Compilation produces a workload-addressable resolved record. At minimum it +contains: + +```yaml +workload_id: ops-bridge-tunnel +workload_ref: + applicability: applicable + rapp_id: null # required for a managed deployable + name: ops-bridge-tunnel + deployable: null # optional for a managed deployable +identity_binding: ssh-certificate/ops-warden/agt-ops-bridge +declared_zone: z2-continuity +admission: satisfied +effective_zone: z2-continuity +membership_revision: sha256: +guarantees: + - authoritative-workload-identity + - explicit-zone-membership + - non-inferred-resolution + - enforcement-time-exception-expiry +controls: + - id: flex-auth/pre-sign + policy_owner: flex-auth + stance: enforced + pep_owner: ops-warden + failure_mode: fail_open + policy_ref: +``` + +The `membership_revision` covers the authoritative workload binding, `zones:` +block, and source revision. Control results include their policy/profile version +and any active exception id and expiry. This is the machine-readable answer to +“which zone is this workload in, and what applies there?” It may be compiled +into existing consumer artifacts; it is not a synchronous zone-engine lookup. + +For managed deployables, compilation consumes the exact Repo Manager reference +projection: + +```yaml +workload_ref: + applicability: applicable + rapp_id: rapp-issue-core + name: issue-core + deployable: issue-core # optional +``` + +The owning catalog uses `applicability: not-applicable` for a native non-workload +subject. Absence of either applicability or an expected reference is `unknown`, +not `not-applicable`. Zone-engine consumes these outcomes; it does not parse a +path or repository name to repair them. + +For flex-auth's pre-sign control, the governed workload is the target of the +certificate or grant, so the compiler writes `workload_id`, `security_zone`, +`security_zone_admission`, and `security_zone_revision` on the resource +attributes. Caller identity remains in the subject. A control that governs the +requesting workload must declare that role explicitly and use separately named +caller-workload attributes. + +The dormant `trust_zone: platform` constant is not security-zone membership and +MUST be retired before adoption. The new concept is named `security_zone`; the +two fields must not coexist as competing zone sources. + +## 8. Membership-change observability + +A membership change becomes effective only through a reviewed declaration and +a newly compiled artifact. The compiler emits the source and membership +revision, rejects ambiguous identities, and reports additions, removals, and +changes against the preceding snapshot. Controls expose the membership revision +in their decision or verdict evidence. + +A zone that can be widened by editing an unversioned runtime label is not +conformant. + +## 9. Time-boxed exceptions + +The normative lifecycle is the T04 decision in +`docs/exception-lifecycle-2026-08-22.md`: only the control owner's designated +authority grants a named-workload, named-zone, named-control relaxation within a +declared maximum duration. Enforcement applies it only for +`not_before <= now < not_after`; invalid or unevaluable records are inactive, +expiry restores the base rule automatically, and no minted credential, lease, +or session may outlive the exception. + +Exceptions live with the versioned control policy or PEP configuration and are +evaluated where their effects occur. This requires no zone-engine runtime. + +## 10. Adoption + +The draft is offered to net-kingdom for publication. Adoption requires: + +1. flex-auth and ops-warden accept the initial control profile or publish a + versioned replacement with total zone and `unknown` coverage; +2. at least two workload owners declare authoritative identities and zones; +3. a third consumer compiles or reads the resolved view; and +4. ops-warden retires `policy.enabled` and the dormant `trust_zone` constant in + the same migration.