529feeac49
source: repo-manager reason: deterministic projection registration Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a058f3-8ba0-7692-a042-9a870fc3d663
129 lines
6.3 KiB
Markdown
129 lines
6.3 KiB
Markdown
---
|
|
id: WARDEN-WP-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: "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?
|
|
|
|
```task
|
|
id: WARDEN-WP-ADHOC-2026-08-17-T01
|
|
status: done
|
|
priority: high
|
|
state_hub_task_id: "04a2f8f9-e70b-5eed-ad87-343c8f9ef501"
|
|
```
|
|
|
|
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: WARDEN-WP-ADHOC-2026-08-17-T02
|
|
status: done
|
|
priority: medium
|
|
state_hub_task_id: "0e815282-2fad-5c8d-be34-398e492737d0"
|
|
```
|
|
|
|
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: WARDEN-WP-ADHOC-2026-08-17-T03
|
|
status: done
|
|
priority: medium
|
|
state_hub_task_id: "e21781d9-a35d-5916-b335-d12131f97a22"
|
|
```
|
|
|
|
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: WARDEN-WP-ADHOC-2026-08-17-T04
|
|
status: done
|
|
priority: low
|
|
state_hub_task_id: "b15724e0-c27a-5260-a810-4dd25bff2228"
|
|
```
|
|
|
|
- [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.
|