---
id: FLEX-WP-0016
type: workplan
title: "In-cluster ops-warden policy pin so policy.enabled can flip"
domain: infotech
repo: flex-auth
status: active
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"
---

# 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
```

**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
```

**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: wait
priority: medium
```

**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. `policy.py` posts JSON with no
`Authorization` header.