codex
1d90aac30f
These workplans exist only in the retired local hub. Their random pre-ADR-007 identifiers are refused by C-06 as stale references, so they cannot be registered. Deriving from the canonical record id takes no identity from anything: central does not hold them and the old ids die with the cache. Records central already holds were deliberately left untouched. Refs CUST-WP-0068-T06 Assistant: claude-code Assistant-Model: opus Assistant-Process: 2583210@bnt-lap001 Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
159 lines
6.8 KiB
Markdown
159 lines
6.8 KiB
Markdown
---
|
|
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.
|