Answer flex-auth caller-auth question; refresh two delegation lanes
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:
parent
263b919c17
commit
3447687bbc
3 changed files with 213 additions and 4 deletions
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue