coulomb/approval-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
approval-engine/deploy/README.md
tegwick fec4eaeb1b Hold the pinned image against the repository's schema 
Schema v4 gave the deployment a silent drift surface: the pinned pair is
self-consistent, migrating to 3 and serving 3, while this repository has
moved to 4. That reads as healthy, which makes it worse than an error —
the failure is the assumption that the deployment records approver
principal type.

Document v4 in storage-operations, state in the deploy runbook that the
pin predates it, and add a test that requires the statement whenever the
release record's schema version differs from this repository's. Verified
to fail when the acknowledgement is removed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad
2026-09-09 14:38:21 +02:00

2.7 KiB
Raw Blame History

Deployment gates

The checked-in StatefulSet is a reviewed release input, not evidence of a live deployment. SQLite is intentionally limited to one replica, ReadWriteOnce storage, and an OnDelete update: never start two writers against a copied database.

Image: pinned, published, not rolled out. Both image: references already carry the immutable release digest sha256:73333f5ceb55e48192e3095cb2e2a741cdc6ff0be2f18128301072b4a6b6eb9d (registry tag 0.1.0, OCI index; linux/amd64 manifest sha256:2064d537…), pinned at b51d174. There is no placeholder left to replace. Both references MUST stay identical and MUST stay digests — a tag here would let the init container and the server run different code against one database.

The pinned image predates schema v4. The published artifact recorded in docs/image-scan-2026-09-06.md carries LATEST_SCHEMA_VERSION = 3; this repository is now at 4 (entries.principal_type, see storage-operations.md). The pinned pair is self-consistent — that image migrates to 3 and serves 3 — so nothing is broken by leaving it pinned, but a rollout that must carry approver principal-type evidence requires cutting a new image at step 3 below. The migrate init container then performs the additive upgrade on the existing volume; tests/test_deploy_manifest.py holds this acknowledgement so the drift cannot go quiet.

Gates 1 and 2 below are the outstanding ones; nothing is deployed today.

Before applying:

  1. Register the exact approval-engine audience, caller scopes, and service clients in KeyCape. Confirm the in-cluster JWKS endpoint and configured issuer match the manifest.
  2. Register approval-engine as an audit-core sender, add matching audit-core ingress, and provision approval-engine-audit through the credential owner. The Secret must contain key audit-token; never commit its value.
  3. For a new release only: make image-release (build, scan, push — the scan gate fails the build on any CRITICAL or HIGH, so a failing scan blocks the push), then pin both image: references to the returned registry digest and run make deploy-dry-run. The current digest is already pinned; skip to 4 unless you are cutting a new image.
  4. Take a verified backup. Roll out by deleting the sole pod, then prove readiness, restart persistence, outbox drain, heartbeat, and restore.
  5. Enable a caller namespace only by applying label railiance.io/approval-engine-client=true; JWT scope checks remain the inner boundary.

The audit-core receiver-side registration, cadence findings, and accepted-count reconciliation are tracked by AUDIT-WP-0009-T04/T06/T09 and cannot be closed from this repository.