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.
5.3 KiB
flex-auth Railiance overlay
Canonical staged-promotion contract for flex-auth (RAIL-BS-WP-0006,
FLEX-WP-0011). The recovered deploy/*.yaml files remain as an emergency
kubectl path; this overlay is the sanctioned shape.
Layout
| Path | Role |
|---|---|
railiance/app.toml |
railiance.app.v1 contract |
charts/flex-auth/ |
One Deployment + Service + NetworkPolicy per release |
values/tenant-engine.yaml |
Production pin for flex-auth-tenant-engine |
values/user-engine.yaml |
Production pin for flex-auth-user-engine |
values/ops-warden.yaml |
Isolated warn pin for ops-warden signing policy (FLEX-WP-0016) |
values/stage2-canary.yaml |
Isolated canary flex-auth-canary (no consumer ingress) |
values/stage3-production.yaml |
Stage 3 values for that same isolated canary release |
tests/stage1.sh |
Local render of every values file |
The two production consumers stay independently pinned and independently
rollable. Do not collapse them into one Helm release. The official
bin/railiance deploy|observe|promote|rollback cycle operates on the
isolated canary so it cannot move a production pin by accident.
Stage 1
tests/stage1.sh
# or
/home/worsch/railiance-bootstrap/bin/railiance run . --pretty
Stage 2 / Stage 3 (isolated canary)
RAILIANCE=/home/worsch/railiance-bootstrap/bin/railiance
$RAILIANCE deploy --stage 2 . --plan
$RAILIANCE deploy --stage 2 . --server-dry-run --pretty
$RAILIANCE deploy --stage 2 . --apply --approval-id <state-hub-id>
$RAILIANCE observe --stage 2 . --live --pretty
$RAILIANCE promote . --plan
$RAILIANCE promote . --apply --approval-id <state-hub-id>
$RAILIANCE rollback . --apply --approval-id <state-hub-id> --revision <helm-rev>
The canary Service is flex-auth-canary.flex-auth.svc.cluster.local:8080.
Production consumers keep calling their own Service names.
Caller-auth promotion (FLEX-WP-0015-T02)
The two production pins are independently rollable. Do not flip both to
enforce in one apply. The first pin of digest
sha256:138aa3471c46bca6e814691fa1e6520aedda3dffd743e6b09141ab433afdb64b
is warn on each consumer.
# Warn pin (safe if a caller still sends no token)
helm upgrade --install flex-auth-user-engine charts/flex-auth \
--namespace flex-auth -f values/user-engine.yaml --wait --timeout 2m
helm upgrade --install flex-auth-tenant-engine charts/flex-auth \
--namespace flex-auth -f values/tenant-engine.yaml --wait --timeout 2m
# Confirm warn logs: "caller authentication warning:" must be absent for a
# migrated caller. user-engine is migrated; tenant-engine live status is
# unconfirmed. Isolated canary keeps callerAuth.mode=disabled.
# Then set values/user-engine.yaml callerAuth.mode: enforce and upgrade only
# that release. USER-WP-0023-T03 runs only after that flip. tenant-engine
# stays warn until its logs are clean.
Emergency kubectl path is also warn. Applying it in enforce is the hazard the warn pin exists to prevent.
Rolling a production pin
Policy is baked into the image. Do not build images on a workstation.
.forgejo/workflows/image.yaml publishes :latest and :main-<short-sha>;
deploy by digest.
# 1. Edit the digest in values/<consumer>.yaml
# 2. Record the previous digest as the rollback target
# 3. Apply only that release
helm upgrade --install flex-auth-<consumer> charts/flex-auth \
--namespace flex-auth -f values/<consumer>.yaml --wait --timeout 2m
# 4. Prove the new policy, not just that the pod started
kubectl -n flex-auth port-forward svc/flex-auth-<consumer> 19099:8080
curl -s -X POST http://127.0.0.1:19099/v1/check \
-H 'Content-Type: application/json' \
-d @examples/<consumer>/<request that exercises the change>.json
Emergency kubectl path (no Helm history): kubectl apply -f deploy/flex-auth-<consumer>.yaml.
Rollback
Preferred: helm rollback flex-auth-<consumer> <revision> -n flex-auth --wait.
If Helm history is missing: kubectl -n flex-auth rollout undo deploy/flex-auth-<consumer>,
or re-apply the last-known-good digest in deploy/README.md.
| Deployment | Last-known-good digest | Policy state |
|---|---|---|
flex-auth-tenant-engine |
sha256:138aa3471c46bca6e814691fa1e6520aedda3dffd743e6b09141ab433afdb64b |
live — caller-auth enforce (FLEX-WP-0015-T02), CI main-3de72fe, A2 probe 2026-08-19 |
flex-auth-tenant-engine (previous) |
sha256:1bf060e61122693ce98359c167cc5fe8bdafc84e097e090eaa71af94d0f27cbc |
nine-action policy (FLEX-WP-0014), CI-built from f304688 |
flex-auth-tenant-engine (previous) |
sha256:9320df394a642eff24da8af4a0ee8886a7bb78b0f14d8ee1deeb30ea8eeeaba7 |
seven-action policy, FLEX-WP-0013 restore |
flex-auth-tenant-engine (rollback) |
sha256:c25fc34a6cd7e64d955f8723ec70e176a583d5ae71d76280c4e2d89fba0fe0aa |
four-action policy; lifecycle actions deny unknown_action |
flex-auth-user-engine |
sha256:138aa3471c46bca6e814691fa1e6520aedda3dffd743e6b09141ab433afdb64b |
live — caller-auth enforce (FLEX-WP-0015-T02), CI main-3de72fe, A2 probe 2026-08-19 |
flex-auth-user-engine (previous) |
sha256:1f5290376dc5fcf456dc7a785e394d8b90949dabecd1d3e856f38557149bb5f4 |
FLEX-WP-0009-T04, nine fixtures, live 2026-08-16 |
flex-auth-user-engine (previous) |
sha256:a31961c45215aa6baf3bc748c6741ab703c2c8325e61aa7983a355026195e51b |
FLEX-WP-0009-T03, six fixtures |