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

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
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
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
Download patch file Download diff file Expand all files Collapse all files

36
workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md
View file

@ -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.