ops-warden/workplans/ADHOC-2026-08-17.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
WARDEN-WP-ADHOC-2026-08-17	workplan	Ad Hoc Tasks — 2026-08-17	infotech	ops-warden	finished	claude	custodian	2026-08-17	2026-08-17	5c6c2bbb-b944-5afd-b89c-20d865518849

Ad Hoc Tasks — 2026-08-17

Inbox triage session. Three unread messages, all follow-on from the WP-0030 delegation register plus one new design question that lands on ops-warden as the estate's workload-identity owner.

T01 — Answer flex-auth: how should /v1/check authenticate its callers?

id: WARDEN-WP-ADHOC-2026-08-17-T01
status: done
priority: high

flex-auth (msg 130a148c, FLEX-WP-0015 T02) reported that POST /v1/check and /v1/batch_check authenticate no caller — any workload with cluster network reach can assert any subject/tenant and receive an authoritative allow. It lands on ops-warden because ops-warden owns how workloads prove identity in this estate, and because the ops-warden pre-sign gate is a flex-auth PEP that would implement the calling side.

Their four questions answered in wiki/NetKingdomSecurityMap.md § Service-to-service caller authentication (in-cluster):

• Q1 — is there an existing estate pattern to adopt? No. Surveyed what exists: ops-warden SSH certs (host reachability, not pod→pod HTTP), KeyCape client_credentials (rapp-qonto-keycape-client — a custodied client secret per caller), OpenBao AppRole (host-standing; the WP-0030 register already flags it as having no owner front door). None covers in-cluster service→service HTTP, so flex-auth is not growing a parallel mechanism by adopting one.
• Q2 — which mechanism? Confirmed their instinct: (a) Kubernetes ServiceAccount TokenReview, with a projected token carrying an explicit audience, keeping automountServiceAccountToken: false and adding the volume per Deployment. Rejected (c) shared-secret header — it manufactures a risk: high credential lane with a rotation owner per caller, on the authorization path, which is exactly the interim-proxy debt WP-0030 exists to stop growing, and ops-warden would end up fronting it. Deferred (b) mTLS as the stronger end state that first needs an answer to who owns the workload X.509 CA — nobody does; ops-warden issues SSH certs, not workload X.509.
• Q3 — authenticate only, or also constrain? Both, but split: bind the asserted system to the authenticated ServiceAccount and reject a mismatch (identity binding, no per-consumer operational cost). Keep the resource-type allowlist ("only ops-warden may ask about ssh-certificate") in the policy package, not in the auth middleware — flex-auth is the policy engine, and encoding it in its own admission layer puts authorization in two places where only one is versioned.
• Q4 — rollout shape? Warn-only first, as they proposed; ops-warden adopts the calling side on its own schedule. Binding condition is sequencing, not a date: policy.enabled must not flip anywhere while /v1/check still answers unauthenticated callers.
• Recorded as a pattern, not a catalog entry — registry/routing/catalog.yaml indexes credential needs and their owners; caller authentication is neither.
• Noted the division of the call: mechanism is ops-warden's/architectural; accepting the pod-spec change and rollout timing are the operator's.

T02 — user-engine: USER_ENGINE_PROXY_SECRET stays railiance-apps; record consumer-only

id: WARDEN-WP-ADHOC-2026-08-17-T02
status: done
priority: medium

user-engine (msg 2af4a124) answered the open confirm question on coulomb-social-runtime-env. Decided by Bernd 2026-08-16, State Hub decision 8fe22037-5bbb-4487-bb86-e4beccee454b against USER-WP-0021: the secret is infrastructure trust between ingress and workload, not a user-domain fact; user-engine consumes it and has no authority over custody, rotation, or issuance.

• intended_owner stays railiance-apps; dropped the now-answered "confirm whether user-engine should front USER_ENGINE_PROXY_SECRET" clause from blocked_on, which now names only the real remaining blocker (CCR not applied).
• Recorded the positive signal they asked for: consumers: [user-engine] on the lane, with the decision id in a comment.
• Their second point — USER_ENGINE_EVENT_TOKEN, USER_ENGINE_MAIL_TOKEN, and the transactional SMTP lane gating public registration — checked against the catalog: audit-core-senders (native → ops-mason) and email-connect-transactional (interim → secrets-engine) already cover the event and mail token custody. No new lane opened; told them which ids to watch.

T03 — key-cape: rapp-qonto-keycape-client interim accepted; refresh the blocker

id: WARDEN-WP-ADHOC-2026-08-17-T03
status: done
priority: medium

key-cape (msg 099b7cba) acknowledged the lane staying interim on ops-warden. KEY-WP-0008 is finished and its closeout does not include a key-cape-native client_secret_basic exchange/rotation command; that is a separate, not-yet-opened workplan.

• Refreshed blocked_on so it names the current reality rather than implying an in-flight KEY-WP-0008 dependency: the native command is unopened work, and key-cape has acked the interim hold.
• key-cape-oidc-login left pointing at secrets-engine — key-cape explicitly did not claim the generic-vs-per-lane custody split, and that lane's blocker is the same unanswered secrets-engine question as the other six.
• reviewed bumped to 2026-08-17 on both touched lanes so warden route gaps staleness reflects a real re-check.

T04 — Session hygiene

id: WARDEN-WP-ADHOC-2026-08-17-T04
status: done
priority: low

• uv run pytest -q → 338 passed, 4 deselected (routing anchor + no-double-source checks green after the catalog edits).
• All three messages replied to and marked read; inbox empty.