ops-warden WARDEN-WP-0031 T04 minted audience-flex-auth tokens as
system:serviceaccount:ops-warden:ops-warden and held the warn-log count.
Helm rev 2 is enforce. Live probe 200/401/403. policy.enabled is theirs.
policy.enabled cannot flip against the user-engine or tenant-engine
bindings. Helm release flex-auth-ops-warden rev 1 serves the production
registry in warn. Workstation warden sends no caller token; enforce and
the yaml flip stay ops-warden's.
flex-auth-tenant-engine Helm rev 2 is enforce on sha256:138aa347 after
tenant-engine 2063470 started sending a projected caller token
(sha256:7dc9d7bf). Probe 200/401/403. tenancy.current.A is 2. T04
cancelled: AuthZEN waits for a PEP we do not control.
Helm-adopted the kubectl-managed user-engine pin, promoted sha256:138aa347
warn then enforce. Reviewer volume needs fsGroup 65532; reviewer tokens
must use the API default audiences or TokenReview 401s on this k3s.
Live probe from user-engine-8569d7cb87-fp7px: 200 / 401 / 403. tenant-engine
is unchanged. tenancy.current.A stays 0 until that pin moves.
The sanctioned Helm chart could not promote ADR 0004 at all, and the
emergency manifests selected enforce. That made a FLEX-WP-0011 apply
either a no-op or a global 401. First production pin is now warn, per
consumer, on CI digest sha256:138aa347… . Enforce stays a later
per-consumer flip so USER-WP-0023-T03 can close without waiting on
tenant-engine.
TokenReview-based caller identity with audience-scoped tokens and exact
resource.system to ServiceAccount bindings, per ops-warden's recommendation.
Deletes the unwired tenant-engine live-roles adapter (T03) and adds
make verify-posture (T05). Source implements A2; running digest is still A0
until promotion, so tenancy.current.A stays 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CI digest sha256:1bf060e6 (main-f304688) is live. Seven pre-existing
actions still allow; guardrail.read/set match the FLEX-WP-0014 split.
user-engine pin unchanged. Rollback target is sha256:9320df39.
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.
T04 is done: nine fixtures including registration-applicant match the
deployed /v1/check, user-engine is on the fail-closed HTTP adapter, and
the deploy manifest now pins the live digest.
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>
flex-auth had no image workflow, so its production images were hand-built
on a workstation and pushed with workstation credentials -- an artifact
whose provenance was someone's working tree rather than a forge revision.
Ports activity-core's canonical image.yaml: the container-build runner
fetches a tarball of the pushed commit, builds, and pushes :latest and
:main-<short-sha>, then reports the immutable digest for the rollout step.
examples/** is a build-trigger path on purpose -- policy packages are
COPYed into the image and there is no hot reload, so a policy change is
an image change.
Runbook updated to say plainly that images are not built on workstations.
FLEX-WP-0011 filed for the rest of the gap: flex-auth runs two production
Deployments on railiance01 but has never been brought under the
staged-promotion contract (RAIL-BS-WP-0006). No railiance/app.toml, no
stage commands, no canary or approval evidence; the deploy/ directory is
a rescue of specs that existed nowhere, not the sanctioned overlay shape.
Pre-existing debt found during the FLEX-WP-0010 rollout, not a regression
from it, and not a blocker for routine policy rollouts -- flex-auth fails
closed. T03 also flags that the coulombcore drain plan still lists
flex-auth on a host it no longer runs on.
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>
