From a9e98da7e29986bc40b2a8b1a2ddc997bbdfecb0 Mon Sep 17 00:00:00 2001 From: tegwick Date: Wed, 19 Aug 2026 22:00:57 +0200 Subject: [PATCH] FLEX-WP-0016: record disposition; SCOPE reflects ADR-0006 and the zone review 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 --- SCOPE.md | 25 +++++++++---- ...WP-0016-ops-warden-incluster-policy-pin.md | 36 +++++++++++++++++++ 2 files changed, 55 insertions(+), 6 deletions(-) diff --git a/SCOPE.md b/SCOPE.md index 65af9ea..a82b4ff 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -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: diff --git a/workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md b/workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md index d6afc80..17ec4e0 100644 --- a/workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md +++ b/workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md @@ -117,3 +117,39 @@ per call; authenticated gate against warn held the warning count at 4 (3) `resource.system=user-engine` → **403** `forbidden`. user-engine and tenant-engine pins were not moved. `policy.enabled` remains ops-warden's flip. + +## Disposition — closed 2026-08-19, not waiting on the flip + +This workplan's title says "so `policy.enabled` can flip", and the flip is not +coming. Recording why that closes it rather than stalls it. + +ops-warden set `ADR-0006` on 2026-08-19: *enforcement is zone-scoped, never a +global flag*. `policy.enabled` is one repo-wide boolean, 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 +now carries the policy call itself. That is a **deliberate deferral of the +control's shape**, not a delay in ops-warden's adoption. The successor is +`zone-engine` `ZONE-WP-0001` (the model) and ops-warden `WARDEN-WP-0032` (the +consumer side); the eventual control will be zone-aware and will not be this +boolean. Nothing in flex-auth's scope will be re-run when it lands. + +Everything this workplan owned is delivered and verified: + +- T01 overlay pin — `values/ops-warden.yaml`, production registry and policy. +- T02 deployed and proven — allow, deny, `/healthz`. +- T03 handoff — ops-warden adopted the calling side (`WARDEN-WP-0031`), the pin + moved to `enforce`, and enforcement is independently verified by both sides: + Bearer → 200 `decision:f3f7c88f9585582a`, anonymous → **401**, wrong system → + **403**. + +**The pin stays `enforce` and is not reverted to `warn`.** An enforcing pin with +no enforcing consumer is not waste: it makes the anonymous path a 401 rather than +a decision, which was the `ADHOC-2026-08-17-T01` condition regardless of whether +ops-warden calls it. Re-verified live 2026-08-19 — +`deploy/flex-auth-ops-warden` carries `--caller-auth-mode enforce` and +`/healthz` is 200 through the managed tunnel +`flex-auth-ops-warden-railiance01` (`:19090`). + +The one open flex-auth-side item is a heads-up obligation, not a task: the tunnel +pins the Service ClusterIP `10.43.1.165`. If that Service is recreated the pin +breaks and ops-warden needs telling.