FLEX-WP-0013. Production had been rolled back to sha256:c25fc34a
(four actions), so tenant.update / tenant.retire / tenant.reactivate
denied unknown_action. Re-pin and apply the previously-live
sha256:9320df39 image (e9911eb). Live probe after restore: all seven
actions allow; misspelled action and unknown subject still deny.
user-engine pin unchanged. TEN-WP-0006 guardrail actions not added.
CI-built image from e9911eb, digest
sha256:9320df394a642eff24da8af4a0ee8886a7bb78b0f14d8ee1deeb30ea8eeeaba7,
verified in a throwaway container before pinning and then probed again
against the live Service after rollout:
tenant.retire allow write_api_policy_matched decision:491bbef2db999c02
tenant.create allow write_api_policy_matched decision:fa3ba90e9cccb5aa
tenant.retired deny unknown_action decision:c5ee185de439ffe5
unknown subject deny unknown_subject decision:a98c59c6a34f84ad
tenant.retire has flipped from deny unknown_action to allow in
production, which is what TEN-WP-0005-T05 was waiting on.
Only flex-auth-tenant-engine was rolled. flex-auth-user-engine stays
pinned to a31961c4 -- its policy is unchanged and there is no reason to
move it. Previous tenant-engine digest kept in the runbook as the
rollback target.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The two flex-auth Deployments were applied from a YAML file that lived
outside this repo, so the only surviving copy of their authored spec was
the last-applied-configuration annotation on the live objects. That made
rollback depend on a cluster annotation -- recovered them into deploy/
before the FLEX-WP-0010 rollout rather than after an incident.
Covers Deployment, Service, and the default-deny NetworkPolicy for both
flex-auth-tenant-engine and flex-auth-user-engine. Verified with
kubectl apply --dry-run=server: Deployments and Services round-trip as
unchanged. The NetworkPolicies report "configured" because the manifests
keep an explicit egress: [] that the API server normalises away -- same
deny-all semantics, documented so nobody chases it.
The runbook records that policy packages are baked into the image with no
hot reload, that both Deployments share one image repo at deliberately
different digests (so roll only the one whose policy changed), and pins
both last-known-good digests as rollback targets.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
