--- id: FLEX-WP-0016 type: workplan title: "In-cluster ops-warden policy pin so policy.enabled can flip" domain: infotech repo: flex-auth status: finished owner: grok topic_slug: netkingdom planning_priority: P1 planning_order: 160 depends_on_workplans: - FLEX-WP-0007 - FLEX-WP-0015 related_workplans: - WARDEN-WP-0009 created: "2026-08-19" updated: "2026-08-19" state_hub_workstream_id: "f29f159c-c79e-5c78-b1e8-569a5b63d231" --- # FLEX-WP-0016 - In-cluster ops-warden policy pin so policy.enabled can flip FLEX-WP-0007 is **finished**. Its repo-side artifacts, tunnel smoke, and vault-backed joint evidence already exist. What it deliberately deferred is the production `policy.enabled: true` flip. That flip is not a flex-auth kubectl of FLEX-WP-0007 leftovers. Three facts now make a new workplan the honest vehicle: 1. FLEX-WP-0015 closed A0 on the two live pins. ops-warden's own sequencing rule (ADHOC-2026-08-17-T01) was: `policy.enabled` must not flip anywhere while `/v1/check` still answers unauthenticated callers. That condition now holds for `flex-auth-user-engine` and `flex-auth-tenant-engine`. 2. Those pins cannot serve ops-warden. Each has an exact `resource.system` → ServiceAccount binding. A `warden sign` check with `system: ops-warden` against either pin is 403, not a signing decision. 3. There is no in-cluster ops-warden policy Service. FLEX-WP-0007 smoke used a workstation runtime on `127.0.0.1:18090` via `flex-auth-coulombcore`. Example `flex_auth_url` `http://flex-auth.flex-auth.svc.cluster.local:8080` does not exist. ## Ownership | Concern | Owner | | --- | --- | | Independently rollable in-cluster pin with the ops-warden policy package and production registry | flex-auth | | Workstation/CoulombCore `flex_auth_url` (tunnel or port-forward) | ops-warden / operator | | Calling-side identity on `warden sign` (TokenReview or later mTLS) | ops-warden, on its own schedule | | `policy.enabled: true` in `warden.yaml` | ops-warden operator | `warden sign` on a laptop is not a Kubernetes ServiceAccount. ADR 0004's choke point therefore cannot be `enforce` on this pin until ops-warden has a calling identity. First pin is **warn**. Enforce and the `policy.enabled` flip wait on that calling side. ## Tasks ```task id: FLEX-WP-0016-T01 status: done priority: high state_hub_task_id: "b2f8052e-3686-593f-9359-dfd08d530a26" ``` **Overlay pin.** Add `values/ops-warden.yaml`: same digest as the A2 pins, `--registry` / `--policy` for `examples/ops-warden/production_registry_snapshot.json` and `policy_package.md`, `callerAuth.mode: warn`, binding `ops-warden=system:serviceaccount:ops-warden:ops-warden`. `consumer.isolated: true` until there is an in-cluster PEP namespace to admit. Include it in `tests/stage1.sh`. Done 2026-08-19: `values/ops-warden.yaml` on digest `sha256:138aa347…`, warn, isolated, production registry. `tests/stage1.sh` renders it. ```task id: FLEX-WP-0016-T02 status: done priority: high state_hub_task_id: "aa65f534-7401-5231-ae82-ea6e3d09b40c" ``` **Deploy warn.** `helm upgrade --install flex-auth-ops-warden` from the overlay. Prove `/healthz` and one allow `/v1/check` from an operator port-forward (isolated NetworkPolicy admits no consumer ingress). Do not flip `policy.enabled`. Done 2026-08-19: Helm release `flex-auth-ops-warden` rev 1, Service `flex-auth-ops-warden.flex-auth.svc.cluster.local:8080`. Port-forward `:19090` `/healthz` 200; `agt-state-hub-bridge` allow `decision:49350f1064f674d7`; TTL 999 deny `ttl_out_of_bounds` `decision:ad1620ffa431efe0`. Unauthenticated calls log `caller authentication warning` and still return a decision (warn). user-engine and tenant-engine pins were not moved. ```task id: FLEX-WP-0016-T03 status: done priority: medium state_hub_task_id: "351f502f-f0cf-5a70-86da-10b1fbe39dae" ``` **Handoff for the flip.** Tell ops-warden the Service DNS, digest, warn mode, and that `policy.py` currently sends no `Authorization` header. They adopt the calling side; then this pin can enforce; then they set `policy.enabled: true` with `fail_closed: true`. Flex-auth does not edit `~/.config/warden/warden.yaml`. Asked 2026-08-19. Cluster DNS from a warden workstation is not assumed; they pick tunnel or port-forward. WARDEN-WP-0031 T04 (2026-08-19): ServiceAccount `ops-warden/ops-warden` exists; `policy.caller_auth mode: command` mints `--audience flex-auth` per call; authenticated gate against warn held the warning count at 4 (`decision:f3f7c88f9585582a`). They asked for enforce. **Enforce live 2026-08-19** Helm rev 2, same digest. Probe via port-forward `:19090` with `kubectl create token ops-warden -n ops-warden --audience flex-auth`: (1) Bearer → 200 `decision:49350f1064f674d7`; (2) no Authorization → **401** `unauthenticated`; (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.