coulomb/approval-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
approval-engine/deploy
History
tegwick c8f85c6d76 Publish and pin the verified schema-v5 approval candidate 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
2026-09-10 19:35:05 +02:00
..
approval-engine.yaml Publish and pin the verified schema-v5 approval candidate 2026-09-10 19:35:05 +02:00
networkpolicies.yaml Implement approval engine production readiness 2026-09-02 00:52:04 +02:00
README.md Publish and pin the verified schema-v5 approval candidate 2026-09-10 19:35:05 +02:00

README.md

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 carry sha256:251941a5cb2724b57cc32cff6b693b1ab0be695bee4f56f02d51961189c0fa49 (registry tag 0.1.0-hfact-be1a388, source be1a388). Both references MUST stay identical immutable digests: migration and server share one database.

The new artifact carries LATEST_SCHEMA_VERSION = 5, matching this source: entries.principal_type and explicit approvals.human_control. Its release scan found zero HIGH/CRITICAL vulnerabilities. Disposable on-disk v4-to-v5 migration, negative service/agent binding, human binding/consumption and restart persistence passed inside the non-root container with no network and a read-only root. See the image evidence. This is artifact evidence; native identity, audit delivery and production restore remain deployment gates. Never roll the old v3 image over a v5 database; use the matching verified pre-migration backup for rollback.

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.