docs(canon): publish security zones v0.1
Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a0291a-1e87-7151-9934-fcbfe3f65eb1
This commit is contained in:
parent
f780289b4f
commit
337484ae16
1 changed files with 336 additions and 0 deletions
336
canon/standards/security-zones_v0.1.md
Normal file
336
canon/standards/security-zones_v0.1.md
Normal file
|
|
@ -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:<digest>
|
||||
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: <versioned-package>
|
||||
```
|
||||
|
||||
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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue