From e85811521059b70ce1d4b449407a7c7f5cac5e80 Mon Sep 17 00:00:00 2001 From: tegwick Date: Tue, 18 Aug 2026 12:53:14 +0200 Subject: [PATCH] Record T03 readiness and the remaining upstream blocker Co-Authored-By: Claude Opus 5 --- docs/flex-auth-caller-identity.md | 11 ++++++---- .../USER-WP-0023-flex-auth-caller-identity.md | 21 +++++++++++++++++++ 2 files changed, 28 insertions(+), 4 deletions(-) diff --git a/docs/flex-auth-caller-identity.md b/docs/flex-auth-caller-identity.md index b97c70e..ccc80b2 100644 --- a/docs/flex-auth-caller-identity.md +++ b/docs/flex-auth-caller-identity.md @@ -1,6 +1,6 @@ # flex-auth caller identity contract -Status: source implemented; production promotion pending. +Status: caller side implemented and deployed; live proof pending flex-auth A2 promotion (FLEX-WP-0015-T02). user-engine calls `flex-auth-user-engine` with a projected Kubernetes ServiceAccount token whose audience is exactly `flex-auth`. The adapter reads @@ -23,9 +23,12 @@ The tenant authority seam is distinct: user-engine identifies itself as actor own flex-auth decision before store access. Tenant ids remain opaque and are URL-encoded. No client may infer existence from an unauthorized read. -The current deployed image predates this file-based caller token. Promote only -with the matching flex-auth A2 image and bindings; otherwise enforcing flex-auth -will correctly return 401 to the old caller. +As of 2026-08-18 the deployed user-engine image carries this file-based caller +token, so the caller side is no longer the laggard. The remaining asymmetry runs +the other way: flex-auth's A2 enforcement is implemented but unpromoted, so the +header is sent and ignored. That ordering is safe — a caller that authenticates +against a service that does not yet check is harmless, whereas the reverse +would have returned 401 to every decision. ## Live promotion probe (USER-WP-0023-T03) diff --git a/workplans/USER-WP-0023-flex-auth-caller-identity.md b/workplans/USER-WP-0023-flex-auth-caller-identity.md index 7cd56c7..ac86853 100644 --- a/workplans/USER-WP-0023-flex-auth-caller-identity.md +++ b/workplans/USER-WP-0023-flex-auth-caller-identity.md @@ -59,4 +59,25 @@ ServiceAccount token manifest. Prove a valid caller succeeds, no token returns 401, and user-engine cannot represent another protected system. This is a live operator rollout and was not performed by the source change. +2026-08-18 readiness review: our half is done. The `rapp-user-engine` managed +package is now the apply home, and image `sha256:c501aeb2…` from `7604d31` — +which contains the caller-token change — is live and passed `make verify-live`. +The projected ServiceAccount token manifest is in place: audience `flex-auth`, +mounted at `/var/run/secrets/flex-auth-caller/token`, with +`USER_ENGINE_FLEX_AUTH_TOKEN_FILE` pointing at it. flex-auth's deploy carries +the binding `user-engine=system:serviceaccount:user-engine:user-engine`. + +The blocker is now precisely one upstream item. FLEX-WP-0015-T02 is `wait`: +ADR 0004's TokenReview choke point exists in flex-auth source, but the running +digest is unchanged, so production still accepts unauthenticated callers and +our Authorization header is sent and ignored. Running the probe today would +pass steps 1 and 3 and silently fail step 2 — a false pass on the only +assertion that proves enforcement. The probe is therefore written down rather +than run: see `docs/flex-auth-caller-identity.md`, which carries all three +checks as commands plus the digests to record. + +This task stays `wait` on FLEX-WP-0015-T02 promotion through FLEX-WP-0011, +and on an operator shell with cluster credentials, which agent sessions in +this repo do not hold. + Contract: `docs/flex-auth-caller-identity.md`.