coulomb/approval-engine
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
approval-engine/deploy/README.md
tegwick e9e9f93317 APPROVAL-WP-0007-T01 done: required_assurance floor; executor ingress; alignment answer 
- Optional required_assurance {"level": aal1|aal2|aal3} at issue, schema v7.
  Enforced at add_entry (403), claim (assurance_unsatisfied) and consume (409)
  from the verified token level only; inherited on supersession; legacy rows
  NULL. Served only when declared so undeclared claims keep exact bytes.
- deploy/networkpolicies.yaml: pod-scoped ingress for sso +
  app.kubernetes.io/name=bounded-executor on 8080 (hub 39a3bffa). Not applied.
- docs/decision-services-alignment-answer.md: owner answer to the NetKingdom
  decision services review (hub 81cafbf3): roles accepted, T02 split proposed,
  presentation_ref at create declined with an entry-level counter-proposal.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 5502@bnt-lap001
Assistant-Session: 68b3b02f-5d0f-4e71-8421-796f62e50196
2026-10-31 23:07:05 +01:00

4.6 KiB
Raw Permalink Blame History

Deployment gates

The StatefulSet is deployed as of 2026-09-14. The metadata receipt is docs/evidence/2026-09-14-approval-engine-deployment.json. SQLite is intentionally limited to one replica, ReadWriteOnce storage, and an OnDelete update: never start two writers against a copied database.

Current image: pinned, published and deployed (2026-10-15). Both image: references carry sha256:16e5d222d58e179f4836f649e8f8128321a8b644d29dc426b4d21a65ff97845d (source a786b061da4d7730c0827cf4919ab9206aed6d3e). Migration and server use identical immutable pins. The scanned image has zero HIGH/CRITICAL findings.

The founder-approved NK-WP-0035 release moved schema v5 to v6 and retained the hourly heartbeat setting. A fresh verified online backup and independent 0600 copy preceded the controlled sole-pod replacement. The new image also opened and migrated an isolated production backup with unchanged record counts. Native readiness and v6 integrity pass; 54 approvals and 47 entries were preserved with zero pending outbox rows. Source defaults and interval settings alone do not establish elapsed-hour or independent receiver acceptance. Receipts: net-kingdom/docs/evidence/2026-10-15-cadence-adoption/ files approval-engine-pre-schema6-backup.json, approval-engine-v6-isolated-restore.json and approval-engine-schema6-rollout.json.

Schema v6 records verified entries.tenant_source; it does not infer legacy provenance. The prior v5 image was sha256:251941a5cb2724b57cc32cff6b693b1ab0be695bee4f56f02d51961189c0fa49. It refuses a v6 store: rollback requires the matching verified pre-v6 backup and the stopped-single-writer restore procedure in docs/storage-operations.md. Source has since moved to schema v7 (approvals.required_assurance, APPROVAL-WP-0007-T01); the pinned image predates schema v7. Deploying v7 needs a new release, a verified pre-v7 backup and a founder-run rollout like the v6 one.

The earlier September v5 release evidence remains historical at the image evidence.

The existing KeyCape consumer registration and CCR-2026-0021 audit projection were already verified by their owners. Live inspection confirmed the projection Ready, exact key name, receiver c82e0442 and existing producer ingress; custody was reused without reading or rotating its value. Added the exact namespace AND pod-label ingress to KeyCape for JWKS (deploy/keycape-ingress.yaml).

The pod requests 25m CPU/64Mi with unchanged 500m/256Mi limits: the node had 3975m of its 4000m CPU reserved, so the prior 50m request could not schedule. Initial native observation was 1m CPU/20Mi. No other workload was resized. Kubernetes token automount is disabled; the service uses no Kubernetes API.

The live service passed schema-v5 integrity, current JWKS reachability, anonymous and invalid-bearer 401, first heartbeat delivery with zero pending outbox, pod replacement with unchanged persisted outbox, verified online backup and an isolated restore opened by the actual engine. An independent 0600 backup copy was inspected locally. No live database was overwritten. The initial backup copies are test evidence, not a long-term backup schedule or disaster-recovery acceptance. Capacity and independent retention remain operational follow-up.

The real PEP adoption is still T05: CCR-2026-0019's operator group/reader, requesting identity and real human approval are not supplied by deployment.

For a future reinstall or release:

  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.