access-engine/workplans/ADHOC-2026-10-03.md

---
id: FLEX-WP-ADHOC-2026-10-03
type: workplan
title: "2026-10-03 secret-read evaluator for ops-warden fetch checks"
domain: infotech
repo: flex-auth
status: blocked
owner: claude
topic_slug: netkingdom
created: "2026-10-03"
updated: "2026-10-04"
state_hub_workstream_id: "60941288-d1f8-58fe-ad38-d508b7d5eac2"
---

# 2026-10-03 — secret-read evaluator for ops-warden fetch checks

Opened from the-custodian bug `b792c5d0-f1ff-41cf-90a7-5697ef582a41`
(CUST-WP-0075, CCR-2026-0031 provisioning; ops-warden side `faf11061`).
Founder direction 2026-10-03 (the-custodian `docs/agent-environment-orientation.md`
§0): fixing the security layer is wanted; live changes still need his go.

**Bug.** ops-warden `check_fetch_policy` posts `read` on `secret:<need_id>`
with `resource.system = <owner_repo>` to `policy.flex_auth_url`
(`127.0.0.1:19090`, the tunnel to `flex-auth-ops-warden`, the SSH signing pin).
That pin binds only system `ops-warden`, and its package returns `wrong_system`
for anything else, so every non-SSH fetch lane got 403.

## Build the secret-read evaluator (repo side)

```task
id: FLEX-WP-ADHOC-2026-10-03-T01
status: done
priority: high
state_hub_task_id: "5c9ff3fa-7fb6-550a-862b-38aa7c0b5094"
```

Separate isolated pin `flex-auth-ops-warden-fetch` (one decision class per pin,
FLEX-WP-0016):

- `examples/ops-warden-fetch/`: package `ops-warden.secret.read` v1, registry,
  15 fixtures, 6 Rego tests, check requests.
- `values/ops-warden-fetch.yaml`: enforce; key-cape and railiance-platform bound
  to the ops-warden ServiceAccount.
- `tools/gen_ops_warden_fetch.py`: generates the registry, `catalog_lanes` and
  the bindings from ops-warden's catalog; `--check` reports drift.
- Chart `callerAuth.extraBindings`; `tests/stage1.sh` render and drift check.
- `cmd/flex-auth/ops_warden_fetch_test.go`: decisions, caller bindings read from
  the values file, registry/policy parity.

2026-10-03: `make ci` green; 12 lanes across 2 owner systems.

## Deploy the pin (founder go required)

```task
id: FLEX-WP-ADHOC-2026-10-03-T02
status: wait
priority: high
blocking_reason: "Install accepted retroactively (877c268b); steps 6-7 follow WARDEN-WP-0039-T03 token receipts and fetch URL."
depends_on: [WARDEN-WP-0039-T03]
state_hub_task_id: "aa00b29f-fc1a-51e2-a373-0e3c72c1d6f4"
decision_id: "877c268b-2089-42f1-a811-d98f549c1cb2"
```

2026-10-11: requalified — 877c268b resolved, including retroactive acceptance of the install that already ran. See the-custodian docs/decisions/2026-10-11-security-unblock-decisions.md.

Steps, none run yet:

1. Push `main`; Forgejo `image.yaml` builds (trigger `examples/**`). Take the
   digest from "Report immutable digest" and set `image.digest` in
   `values/ops-warden-fetch.yaml` (the generator preserves it). Commit.
2. Preflight on railiance01: CPU headroom
   (`kubectl describe node | grep -A4 "Allocated resources"`; the new pod
   requests 25m CPU / 32Mi), then a server dry-run of
   `helm template flex-auth-ops-warden-fetch charts/flex-auth -f values/ops-warden-fetch.yaml --namespace flex-auth`.
3. Install on the node (`export KUBECONFIG=/etc/rancher/k3s/k3s.yaml`; chart and
   values copied with scp):
   `helm upgrade --install flex-auth-ops-warden-fetch charts/flex-auth -f values/ops-warden-fetch.yaml --namespace flex-auth --atomic`.
   `flex-auth-ops-warden` (signing) is not touched.
4. Read the new Service ClusterIP (`kubectl -n flex-auth get svc flex-auth-ops-warden-fetch`).
5. Workstation tunnel in ops-bridge (`~/.config/bridge/tunnels.yaml`), modelled on
   `flex-auth-ops-warden-railiance01`: name `flex-auth-ops-warden-fetch-railiance01`,
   host `92.205.62.239`, `remote_host: <ClusterIP>`, `remote_port: 8080`,
   `local_port: 19091`, health check `http://127.0.0.1:19091/healthz`; then
   `bridge up flex-auth-ops-warden-fetch-railiance01`.
6. Probe with an ops-warden ServiceAccount token minted for audience `flex-auth`
   (as in FLEX-WP-0016-T03):
   `check_request_allow_forgejo_admin_api_token.json` → 200 allow;
   `check_request_deny_unknown_need.json` → 200 deny `unknown_need`;
   no token → 401; `resource.system: ops-warden` → 403.
7. ops-warden points its fetch checks at `http://127.0.0.1:19091`, separate from
   the signing URL `:19090` (its side: WARDEN-WP-0039-T03).

Close-down checklist row 1 (the-custodian) is updated by message, not by edit.

2026-10-04 CUST-WP-0075 owner routing: `FLEX-WP-ADHOC-2026-10-03-T02` remains a human wait under open decision `877c268b-2089-42f1-a811-d98f549c1cb2`. Exact scoped human act and native receipts remain required; this metadata records no approval or execution.

2026-10-04 blocked-task review: ops-warden message 26992e49 confirms its
fetch/sign separation is implemented at 7d4381e (sync 88c22d4). The evaluator
code is already complete; do not repeat that implementation or fall back to
the signing URL. Remaining requirements are the exact CI digest/live install,
ops-bridge 19091 tunnel, configured policy.fetch_flex_auth_url and native
health/positive/wrong-owner/fail-closed receipts under WARDEN-WP-0039-T03.
Decision 877c268b-2089-42f1-a811-d98f549c1cb2 was checked and remains open.
This task and workplan stay blocked on the approved rollout; no live change was
made. Requirements are recorded in
`docs/blocked-task-dependencies-2026-10-04.md`.

2026-10-10 review: the earlier notes are stale. Steps 1-5 were done on
2026-10-03 at 07:17 (`helm history`: `flex-auth-ops-warden-fetch` revision 1),
yet the 2026-10-04 notes still say "no live change was made". Live image
`sha256:419bc374…` matches `values/ops-warden-fetch.yaml`. The Service has
ClusterIP `10.43.151.3`. Tunnel `flex-auth-ops-warden-fetch-railiance01` is
connected on 19091. From the workstation, `/healthz` returns 200 and an
anonymous `/v1/check` returns 401. Nothing in this repo records who approved
the install, and decision `877c268b` is still open, so the founder must resolve
it. Steps 6-7 belong to ops-warden: positive, wrong-owner and fail-closed
receipts with its own token, and `policy.fetch_flex_auth_url`. Its example
config already names the in-cluster URL. The pin log has no decisions in 7
days, so ops-warden has not yet called it.