tegwick
9491d1d3a7
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a13eab-1e6a-7b33-9c37-372e90ada3a2
76 lines
4.4 KiB
Markdown
76 lines
4.4 KiB
Markdown
# 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`.
|
|
The earlier September v5 release evidence remains historical at
|
|
[the image evidence](../docs/evidence/2026-09-10-human-control-image.json).
|
|
|
|
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.
|