flex-auth/workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	planning_order	depends_on_workplans	related_workplans	created	updated	state_hub_workstream_id
FLEX-WP-0016	workplan	In-cluster ops-warden policy pin so policy.enabled can flip	infotech	flex-auth	finished	grok	netkingdom	P1	160	FLEX-WP-0007 FLEX-WP-0015	WARDEN-WP-0009	2026-08-19	2026-08-19	5c0fac68-284d-4672-9824-8686a902d33f

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

id: FLEX-WP-0016-T01
status: done
priority: high
state_hub_task_id: "3d7fde8e-00b1-4bc3-be28-00afd37997ac"

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.

id: FLEX-WP-0016-T02
status: done
priority: high
state_hub_task_id: "9f30410f-e2b3-4b0a-9d70-6f6a12d2822e"

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.

id: FLEX-WP-0016-T03
status: done
priority: medium
state_hub_task_id: "65df7141-58f0-4be8-bc62-07f29cb96856"

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.