coulomb/zone-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

ZONE-WP-0001: flex-auth amendments as the consuming PDP

Browse source 
Reviewed as the only policy decision point. Four task amendments:

T01 - the 'only PDP' invariant guards latency, not authority. Compiled
data that determines an outcome still decides. Tightened wording:
zone-engine owns membership, flex-auth policy owns stance.

T03 - split membership from stance rather than rejecting option (c)
wholesale. Stance for the pre-sign gate belongs in the policy package
because registry content is absent from decision provenance. Also:
fail-open is a PEP property and no PDP can express it.

T05 - no registry schema change needed; metadata/attributes already
flatten into rego input. But trust_zone is a live name collision -
a hardcoded 'platform' constant no policy reads.

T04 - flex-auth loads registry and policy once at process start with
no reload path, so an inert compiled exception expires only by human
redeploy. Enforced expiry requires a not_after evaluated in rego.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-19 21:59:47 +02:00
parent b2800e10a7
commit 9de50d3a48
1 changed files with 128 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

128
workplans/ZONE-WP-0001-security-zone-model.md
View file

@ -58,6 +58,15 @@ compiled registry snapshot built by
decision point by **compilation**. A synchronous zone lookup in the decision
path would be a regression dressed as an architecture.
> **flex-auth reviewed this workplan on 2026-08-19** as the PDP that would have
> to live with the result, and amended T01, T03, T04 and T05 in place. The three
> substantive changes: the "only PDP" invariant needs to bind *authority* and not
> only latency (T01); membership compiles to the registry but **stance belongs in
> the policy package**, and fail-open is not expressible by a PDP at all (T03);
> and flex-auth has **no reload path**, which decides how a time-boxed exception
> can possibly expire (T04). Membership itself needs **no registry schema
> change** — but do not land it on the existing `trust_zone` field (T05).
**`warden plan`** (ops-warden WP-0029) — already returns
`autonomous`/`founder_required`/`unroutable` from properties of the thing, with
the `reasons` that produced the verdict. Zone-aware enforcement extends that
@ -82,6 +91,27 @@ the only PDP and consumes compiled membership.
If either disagrees, the model moves and this repo is archived rather than kept
for its own sake. Record the outcome either way.
**flex-auth answered 2026-08-19 (amended by flex-auth).** Confirmed: zone-engine
owns zone identity, membership and exception lifecycle; flex-auth stays the only
PDP. But the invariant as written in `GOAL.md` guards the wrong property. *"Never
a synchronous lookup in a decision path"* is a **latency** guarantee. It does not
guarantee flex-auth remains the only decision point, because compiled data that
determines an outcome is still deciding — it just decided earlier. Under the
invariant as written, zone-engine could compile `enforced: false` for a lane and
flip `warden sign` from deny to allow without a flex-auth policy change, and
still be literally compliant.
The invariant flex-auth confirms is the tighter one:
> zone-engine is the authority over zone **identity and membership**. The
> **effect** of a zone on any decision flex-auth renders is expressed in a
> flex-auth policy package — versioned, fixtured, tested, and stamped into the
> decision record. Membership is data and is compiled. Stance is a rule and is
> policy.
Rationale is in T03. Please carry the tightened wording into `GOAL.md`; the
current wording is not wrong, it is just not load-bearing.
```task
id: ZONE-WP-0001-T02
status: todo
@ -124,6 +154,48 @@ Controls in scope at minimum: the flex-auth pre-sign gate (`policy.enabled`,
`fail_closed`), the agent read-boundary on `risk: high` lanes (ops-warden
`ADR-0004`), and the `warden plan` escalation verdicts.
**Amended by flex-auth 2026-08-19 — split membership from stance.** ops-warden's
option (c) ("zones as policy-package data") was rejected wholesale because the
model must govern two controls flex-auth does not evaluate. flex-auth agrees with
the premise and disagrees with the conclusion: (c) was rejected at the wrong
granularity. *Where a stance is evaluated belongs with the control's enforcement
point*, and there are three enforcement points here, not one:
| Control | Enforcement point | Where its per-zone stance belongs |
| --- | --- | --- |
| flex-auth pre-sign gate | flex-auth (PDP) + `warden sign` (PEP) | **flex-auth policy package** |
| Agent read-boundary (`ADR-0004`) | ops-warden CLI | ops-warden — flex-auth never sees it |
| `warden plan` escalation verdicts | ops-warden CLI | ops-warden — flex-auth never sees it |
So (b) is right for two of three controls and wrong for the one that is
flex-auth's. Concretely, for the pre-sign gate:
- **Membership → compiled registry.** Which zone an actor/lane is in is data,
varies per resource, changes as the estate changes, and is already produced by
`build_flex_auth_registry.py`. Compile it.
- **Stance → policy package.** "In zone X the gate is advisory" is a rule about
outcomes. It belongs in the artifact that already carries fixtures, rego tests,
`Validate()`, a version, and a status.
The concrete defect in compiling stance: every flex-auth decision envelope stamps
`matched_policy_version`, `policy_package` and `policy_status`, and the decision
id is derived from policy metadata plus request
(`internal/decision/engine.go:358`). Registry content is **not** in that
provenance. If zone stance lives in the registry, a stance change alters the
verdict while the decision record still reports the same policy version — two
decisions, same version, same request, different effect, and nothing in the audit
trail explains why. That breaks flex-auth's reproducibility contract for exactly
the control this workplan exists to make safe.
**Second correction: flex-auth cannot express fail-open.** A PDP returns an
effect. "Fail-open" describes what the caller does when flex-auth is
*unreachable* — that is a property of ops-warden's client (`fail_closed` in
`warden.yaml`), and no zone data compiled into flex-auth can influence it. Model
the failure-mode axis as **PEP-side**, owned by each consumer's declaration, not
as something the PDP carries. `enforced`/`advisory`/`exempt` *is* expressible by
flex-auth (as effect plus an advisory annotation in the envelope); fail-open is
not, and a model that implies otherwise will be built and then not work.
```task
id: ZONE-WP-0001-T04
status: todo
@ -144,6 +216,31 @@ happens at expiry — auto-revert, or block until renewed.
If T04 concludes the lifecycle can live as reviewed declarations in git, say so
plainly and drop the runtime. That is a valid and cheaper outcome.
**Hard constraint from flex-auth 2026-08-19 — the PDP has no reload path.**
`cmd/flex-auth/main.go:447` calls `registry.LoadFile` once at process start.
There is no watcher, no SIGHUP, no reload endpoint. Both the registry snapshot
*and* the policy package are baked into the container image and the production
pins are digest-pinned (`values/ops-warden.yaml`,
`sha256:138aa347…`). Changing either means: rebuild image → new digest → helm
upgrade → pod restart.
This is the input T04 most needs, and it kills one design outright:
- **An exception compiled as inert registry data cannot have an enforced
expiry.** It expires when a human rebuilds and redeploys. That is expiry by
intention — precisely what this task says it must not be.
- **An exception carrying its own `not_after` timestamp, evaluated against
decision time in rego, does have an enforced expiry.** OPA has a clock
(`time.now_ns()`); the grant costs a redeploy but the *lapse* is automatic and
needs nobody. The zone widens by deploy and narrows by itself, which is the
correct asymmetry.
That is a third argument for stance-in-policy independent of the audit one in
T03, and it also bears on whether this repo earns a runtime: if expiry is
evaluated at decision time from a compiled timestamp, the lifecycle needs a
*record and a review*, not a service. flex-auth's read is that this points at the
cheaper outcome, but it is T04's call.
```task
id: ZONE-WP-0001-T05
status: todo
@ -156,6 +253,37 @@ with evidence, `reviewed`, and `review_due`; carry over *accuracy, not
altitude*. Include how a zone assignment changes and how that change is
observed — a zone that can be quietly widened is not a boundary.
**Two carrier facts from flex-auth 2026-08-19 (no schema change needed).**
Compiled zone membership is expressible in flex-auth's registry format **today**,
with zero Go changes. Every registry entity carries `metadata`; `api.Resource`
additionally carries `labels`, `owner`, `attributes` and `trust_zone`, and
`internal/decision/engine.go:275` flattens all of them into
`input.resource.attributes` before evaluation. `subject.metadata` and
`subject.claims` are flattened the same way (`engine.go:257`). A compiler writing
`"security_zone": "..."` into a resource's `attributes` makes it readable from
rego as `input.resource.attributes.security_zone`. Nothing to build.
Two things to decide anyway, and both belong in this task:
1. **Do not reuse `trust_zone` — this collision has already happened inside the
PDP.** `api.Resource.TrustZone` is a first-class field, is surfaced into rego
input, and `ops-warden/scripts/build_flex_auth_registry.py:77` sets it to the
hardcoded constant `"platform"` on every ssh-certificate resource. No policy
package reads it. It is a dormant, plausibly-named, semantically-empty field
sitting exactly where a reader would expect zone membership to go. `SCOPE.md`
warns that "zone" is overloaded and names network segmentation as the hazard;
the actual live collision is this one. Name the new concept `security_zone`
explicitly, or deliberately repurpose `trust_zone` and say so loudly — but do
not let both exist meaning different things.
2. **Say whether membership rides the subject or the resource.** In the
ops-warden registry an actor appears as *both*: as a subject
(`agt-state-hub-bridge`) and as a per-actor resource
(`ssh-cert:actor/agt-state-hub-bridge`). If T02 concludes a zone is a property
of the actor, the compiler must be told which record carries it — or write
both and make that the contract. Leaving it implicit produces two compilers
that disagree. This is a compiler contract, not a schema change.
```task
id: ZONE-WP-0001-T06
status: todo