FLEX-WP-0016: record disposition; SCOPE reflects ADR-0006 and the zone review
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

FLEX-WP-0016 was titled 'so policy.enabled can flip' and the flip is not
coming. ops-warden's ADR-0006 defers it permanently in favour of
zone-scoped enforcement, so this closes rather than stalls: every task
it owned is delivered and enforce is independently verified by both
sides. The pin stays enforce and is not reverted to warn.

SCOPE's account of policy.enabled was stale - it read as a
build-stage timing choice. Replaced with the actual reason and with
flex-auth's boundary as the reviewing PDP: membership compiles to the
registry, stance stays in the policy package, fail-open is not
expressible by a PDP.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-19 22:00:57 +02:00
parent ee6d66c005
commit a9e98da7e2
2 changed files with 55 additions and 6 deletions

View file

@ -90,12 +90,25 @@ fixtures, and tests). `FLEX-WP-0006` published that gate and `FLEX-WP-0007`
deployed flex-auth as a reachable production runtime for it. The joint
OpenBao-backed smoke is verified (2026-06-29: vault-backed allow recorded
`decision:032b096c433ad80c`; TTL-over-max denied `ttl_out_of_bounds` by
flex-auth before OpenBao). Production `policy.enabled` is **deliberately left
off** for now — the ecosystem is still build-stage/pre-testing, so the gate is
verified and banked for later live enforcement rather than forced into premature
production rigor. With the baseline complete, new work (live enforcement
rollout, additional consumers, deeper delegated backends) will open as fresh
workplans.
flex-auth before OpenBao). `FLEX-WP-0016` then shipped an independently rollable
in-cluster ops-warden pin and moved it to `callerAuth.mode: enforce` once
ops-warden adopted a calling identity (`WARDEN-WP-0031`): anonymous `/v1/check`
is 401, a token bound to another protected system is 403.
Production `policy.enabled` is **deliberately off, and is not coming back as a
boolean.** ops-warden's `ADR-0006` (2026-08-19) defers it permanently:
`policy.enabled` is one repo-wide flag, and with `fail_closed: true` it makes
flex-auth a hard dependency of every `warden sign` — including the SSH
certificates the ops-bridge tunnels depend on, one of which carries the policy
call itself. Enforcement is being rescoped to *security zones* (`zone-engine`
`ZONE-WP-0001`, consumer side `WARDEN-WP-0032`). flex-auth reviewed that model as
the PDP on 2026-08-19 and holds one boundary: zone **membership** compiles into
the registry snapshot flex-auth already consumes (no schema change needed), while
per-zone **stance** belongs in the versioned policy package, because registry
content is absent from decision provenance. **Fail-open is not expressible by a
PDP at all** and stays a consumer-side setting. The enforcing pins stay
enforcing regardless — an enforcing pin with no enforcing consumer still turns
the anonymous path into a 401 rather than a decision.
State Hub integration is present through: