tegwick
5c45d3c157
Founder decision 2026-11-01, relayed by the net-kingdom coordinator: "Agree to split APPROVAL-WP-0007-T02: build actor_consumes now (opt-in at issue; the bounded executor will set it); principal_approves keeps waiting for the KeyCape subject mapping." - Optional actor_consumes (boolean) at issue, schema v8. Consume refuses with 403 unless the consuming subject equals binding.actor, also on idempotent retries; internal calls without a consumer fail closed. Inherited on supersession (existing-successor mismatch 409), in audit details, served in GET/claim only when declared so undeclared claims keep exact bytes. Legacy rows migrate without the flag. - GH-DEC-2026-026 Ruling 6: under human_control, add_entry refuses (403) the binding actor as approver. human_control already covered a service actor; this covers a human actor. - Workplan: T02 done (actor_consumes); new T05 principal_approves (wait). - Not released or deployed: needs a v8 image and founder-run rollout. 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
81 lines
4.7 KiB
Markdown
81 lines
4.7 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`.
|
|
Source has since moved to schema v8 (v7 `approvals.required_assurance`,
|
|
APPROVAL-WP-0007-T01; v8 `approvals.actor_consumes`, APPROVAL-WP-0007-T02); the
|
|
pinned image predates schema v8 (and v7). Deploying 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](../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.
|