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

Record the warn-first promotion sequence and operator gate on T02
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Build and Publish Container Image / build-and-push (push) Successful in 40s
Details

Browse source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-18 15:24:16 +02:00
parent 1e1e077b27
commit 3de72fe6f5
1 changed files with 35 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

37
workplans/FLEX-WP-0015-tenancy-posture-conformance.md
View file

@ -113,8 +113,41 @@ the choke point; missing/mismatched identity fails 401/403 and reviewer outage
fails 503. Unit and handler tests include the required unbound request. Desired
manifests select enforce mode and carry narrow TokenReview RBAC. The running
digest is unchanged, so `tenancy.current.A` honestly remains 0 while
`tenancy.implemented.A` is 2. Remaining: build/pin/promote through
FLEX-WP-0011, migrate both callers and capture the live negative probe.
`tenancy.implemented.A` is 2. Source committed as `1e1e077`.
**Remaining, in this order — the sequence is a constraint, not a preference.**
`ops-warden` ruled on rollout (2026-08-17) and `user-engine` asked for the same:
1. Build and pin a new immutable digest carrying the caller-auth code.
2. Promote it in **`warn` mode**, not `enforce`. The reviewed desired manifests
in `deploy/` select `enforce` because that is the end state — applying them
directly is the hazard. Warn authenticates and logs failures without
rejecting, so it is safe for an unmigrated caller.
3. Confirm the warn logs are clean of unauthenticated callers. `user-engine` is
migrated and deployed as of 2026-08-18 (image `sha256:c501aeb2…`, token at
`/var/run/secrets/flex-auth-caller/token`). `tenant-engine`'s caller status
is **unconfirmed — asked 2026-08-18**; promoting `enforce` while their
client sends no token 401s every check and blocks their write paths.
`ops-warden` adopts the calling side on its own schedule.
4. Flip to `enforce`, then capture the live negative probe. `user-engine` has
the three assertions written and ready in their
`docs/flex-auth-caller-identity.md`; they deliberately have not run it,
because against an unenforced digest "no token returns 401" comes back as a
normal decision and would record as false evidence.
5. Only then may `policy.enabled` flip anywhere — `ops-warden` names that the
real deadline, and it is the same gate as FLEX-WP-0007.
**Operator gate.** Steps 1–4 need cluster credentials this session does not
have: `kubectl` returns `Unauthorized` and the context is `default`, which
`tenant-engine` documented on 2026-08-16 as indistinguishable from a
wrong-cluster KUBECONFIG. Promotion follows FLEX-WP-0011 staged promotion and
the CI image build, not a hand-built image.
`RISK-F-0001` (risk-nexus) tracks this A0 externally. Their NetworkPolicy
question was answered 2026-08-18: both Deployments carry an ingress policy
restricted to one namespace *and* one pod label, predating this work — so the
reachable set was never "any pod in the cluster", and a sentence of mine that
said so was corrected to them.
```task
id: FLEX-WP-0015-T03