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

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
FLEX-WP-ADHOC-2026-10-03	workplan	2026-10-03 secret-read evaluator for ops-warden fetch checks	infotech	flex-auth	blocked	claude	netkingdom	2026-10-03	2026-10-04	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)

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)

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.