tegwick
d710bf0088
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a09cbb-87c6-7900-a145-4ce53ba9f1a6
66 lines
3.9 KiB
Markdown
66 lines
3.9 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.
|
|
|
|
**Image: pinned, published and deployed.** 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](../docs/evidence/2026-09-10-human-control-image.json).
|
|
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.
|
|
|
|
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.
|