coulomb/user-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Close USER-WP-0023 after live A2 enforce evidence
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
flex-auth-user-engine is enforce on sha256:138aa347. Probe from
user-engine-8569d7cb87-fp7px: 200 with the projected token, 401 without,
403 when representing tenant-engine. Record fsGroup 10001 so uid 10001
can read the projected caller token.
This commit is contained in:
tegwick 2026-08-19 14:24:33 +02:00
parent c405215a20
commit 108bb9a2de
2 changed files with 44 additions and 25 deletions
Download patch file Download diff file Expand all files Collapse all files

49
docs/flex-auth-caller-identity.md
View file

@ -1,6 +1,6 @@
# flex-auth caller identity contract
Status: caller side implemented and deployed; live proof pending flex-auth A2 promotion (FLEX-WP-0015-T02).
Status: live A2 proven 2026-08-19 on `flex-auth-user-engine` (`enforce`).
Governing published policy (2026-08-19):
@ -31,12 +31,14 @@ 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.
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.
As of 2026-08-19 `flex-auth-user-engine` is live `enforce` on digest
`sha256:138aa347…` (Helm release rev 4). user-engine `sha256:c501aeb2…`
sends the projected token. The pod security context must set
`runAsUser` / `runAsGroup` / `fsGroup` `10001` (image uid; see
Containerfile). Without `fsGroup`, the projected token is `0440 root:root`
and the adapter never sends `Authorization`. That is persisted in
rapp-user-engine `manifests/runtime.yaml` `e599b4f`. The portal image has
no `curl`; live probes use Python.
## Live promotion probe (USER-WP-0023-T03)
@ -45,16 +47,12 @@ runs in namespace `user-engine` as ServiceAccount `user-engine`, with the
projected token mounted at `/var/run/secrets/flex-auth-caller/token` under
audience `flex-auth` and `USER_ENGINE_FLEX_AUTH_TOKEN_FILE` pointing at it.
**This probe cannot pass yet, and the reason is upstream.** FLEX-WP-0015-T02
is `wait`: ADR 0004's TokenReview choke point is implemented in flex-auth
source, but the running digest is unchanged, so production still accepts
unauthenticated callers. Our Authorization header is currently sent and
ignored. Run the probe only after flex-auth promotes A2 through
FLEX-WP-0011; before then step 2 returns a normal decision instead of 401 and
would record a false pass.
Closed 2026-08-19 after `flex-auth-user-engine` flipped to `enforce`.
Do not re-run these against `warn`: step 2 would return a decision.
Run from an operator shell with cluster credentials (this repo's sessions do
not hold them). `POD` is any ready user-engine pod.
`POD` is any ready user-engine pod. The portal image has no `curl`; the
recorded run used Python. The bash shape below is the contract, not the
exact live invocation.
```bash
POD=$(kubectl -n user-engine get pod -l app.kubernetes.io/name=user-engine \
@ -89,9 +87,19 @@ BODY='{"actor":{"issuer":"https://kc.coulomb.social","subject":"probe",
A2 choke point named by Tenancy Posture v0.1; publication does not change
the remaining operator sequence.
Record all three results, the flex-auth digest they ran against, and the
user-engine digest, in USER-WP-0023-T03 before marking it done. A pass on
steps 1 and 3 without a 401 on step 2 means enforcement is still off.
Recorded 2026-08-19 from pod `user-engine-8569d7cb87-fp7px` (flex-auth
message `45852487`):
| Step | Result |
| --- | --- |
| 1. Bearer projected token | `200` `decision:350b46fb42989606` allow `tenant_admin` |
| 2. No Authorization | `401` `unauthenticated` |
| 3. `resource.system=tenant-engine` | `403` `forbidden` |
Digests: flex-auth `sha256:138aa3471c46bca6e814691fa1e6520aedda3dffd743e6b09141ab433afdb64b`,
user-engine `sha256:c501aeb204154d85017565a87fd34cff12e5c48f600d124d3f8c82f11bb9d59c`.
tenant-engine and `policy.enabled` were not moved. A pass on steps 1 and 3
without a 401 on step 2 would have meant enforcement was still off.
## Live cross-service check (USER-WP-0021)
@ -108,5 +116,4 @@ and no `404`, which is what the rollback window produced. Capture the
tenant-engine digest alongside the results; both silent rollbacks this month
were digest-level and neither raised an alert.
This shares the operator rollout with the T03 probe above and is most
efficiently run in the same session.
This remains owed. It was not run in the 2026-08-19 A2 session.