Answer flex-auth caller-auth question; refresh two delegation lanes
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

Inbox triage (ADHOC-2026-08-17), three messages, all answered and marked read.

flex-auth (FLEX-WP-0015 T02) reported that /v1/check and /v1/batch_check
authenticate no caller — any workload with cluster reach can assert any subject
and get an authoritative allow. It lands here because ops-warden owns workload
identity in this estate and its pre-sign gate is a flex-auth PEP.

Recommendation recorded in wiki/NetKingdomSecurityMap.md: Kubernetes
ServiceAccount TokenReview with a projected, audience-scoped token. Rejected the
shared-secret header — it manufactures a risk: high lane with a rotation owner
per caller on the authorization path, the exact interim-proxy debt WP-0030
exists to stop growing. Deferred mTLS pending an owner for a workload X.509 CA.
Bind `system` to the authenticated SA at auth time, but keep the resource-type
allowlist in the policy package rather than the admission layer. Warn-only
rollout; policy.enabled must not flip while /v1/check answers unauthenticated
callers. Recorded as a pattern, not a catalog entry.

Catalog delegation refreshes:
- coulomb-social-runtime-env: USER_ENGINE_PROXY_SECRET ownership settled
  (decision 8fe22037, USER-WP-0021) — intended_owner stays railiance-apps,
  answered clause dropped from blocked_on, consumers: [user-engine] recorded.
- rapp-qonto-keycape-client: blocked_on no longer implies an in-flight
  KEY-WP-0008 dependency; the key-cape-native exchange command is unopened work.

uv run pytest -q → 338 passed, 4 deselected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-17 22:55:33 +02:00
parent 263b919c17
commit 3447687bbc
3 changed files with 213 additions and 4 deletions

View file

@ -543,8 +543,8 @@ entries:
delegation:
mode: interim
intended_owner: key-cape
blocked_on: "client_secret_basic exchange is a key-cape protocol procedure, not a KV read; rotation already automatable"
reviewed: "2026-08-11"
blocked_on: "client_secret_basic exchange is a key-cape protocol procedure, not a KV read; KEY-WP-0008 finished 2026-08-15 without a key-cape-native exchange/rotation command, and the workplan that would add one is not yet opened (key-cape acked interim 2026-08-15)"
reviewed: "2026-08-17"
risk: high
auth_method: "OpenBao platform workload lane; KeyCape client_secret_basic exchange"
path_template: "platform/workloads/rapp-qonto/keycape-client"
@ -731,8 +731,13 @@ entries:
delegation:
mode: interim
intended_owner: railiance-apps
blocked_on: "Runtime Secret applied via railiance-apps make target; OpenBao path planned; confirm whether user-engine should front USER_ENGINE_PROXY_SECRET"
reviewed: "2026-08-15"
blocked_on: "Runtime Secret applied via railiance-apps make target; OpenBao path planned but CCR not applied"
reviewed: "2026-08-17"
# USER_ENGINE_PROXY_SECRET ownership settled 2026-08-16 (Bernd; State Hub decision
# 8fe22037-5bbb-4487-bb86-e4beccee454b, USER-WP-0021): it is infrastructure trust
# between ingress and workload, not a user-domain fact. intended_owner stays
# railiance-apps; user-engine is consumer-only and claims no lane here.
consumers: [user-engine]
risk: standard
# K8s assembly is the live handoff today (same pattern as vergage-teilnahme-env).
# OpenBao KV platform/workloads/coulomb/coulomb-social/runtime-env is the