--- id: ADHOC-2026-08-17 type: workplan title: "Ad Hoc Tasks — 2026-08-17" domain: infotech repo: ops-warden status: finished owner: claude topic_slug: custodian created: "2026-08-17" updated: "2026-08-17" state_hub_workstream_id: "c8b0e623-4e89-41aa-b561-5dee9c7dad03" --- # 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? ```task id: ADHOC-2026-08-17-T01 status: done priority: high state_hub_task_id: "c67ccc00-00e5-4fc9-9b51-b3c7d5ab5741" ``` 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)*: - [x] **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. - [x] **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. - [x] **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. - [x] **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. - [x] Recorded as a **pattern**, not a catalog entry — `registry/routing/catalog.yaml` indexes credential needs and their owners; caller authentication is neither. - [x] 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 ```task id: ADHOC-2026-08-17-T02 status: done priority: medium state_hub_task_id: "be453158-ca91-404e-a4dc-01f1ee0884cf" ``` 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. - [x] `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). - [x] Recorded the positive signal they asked for: `consumers: [user-engine]` on the lane, with the decision id in a comment. - [x] 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 ```task id: ADHOC-2026-08-17-T03 status: done priority: medium state_hub_task_id: "18e6958f-61ad-4e12-a008-79652611feae" ``` 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. - [x] 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. - [x] `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. - [x] `reviewed` bumped to 2026-08-17 on both touched lanes so `warden route gaps` staleness reflects a real re-check. ### T04 — Session hygiene ```task id: ADHOC-2026-08-17-T04 status: done priority: low state_hub_task_id: "874f6c76-ef1b-454a-a3f1-bbf74e087acd" ``` - [x] `uv run pytest -q` → 338 passed, 4 deselected (routing anchor + no-double-source checks green after the catalog edits). - [x] All three messages replied to and marked read; inbox empty.