Vault KMS rollout verification

2026-09-13 — staging AWS forward/outage/reverse acceptance passed. Vault #241 tracks implementation, release and hosted acceptance separately. The disabled rollout verified epoch-aware writers first. The subsequent enabled rollout passed the same source, image, task and authenticated capability gate.

The read-only rollout check verifies a completed deployment, every running staging-service task, the reviewed source revision, ECR image digest, runtime flag and authenticated API capability. It emits metadata only and does not change cloud resources, vault entries or configuration. The existing session file stays private; credentials never appear in command arguments.

shell

python3 infra/vault/verify-migration-rollout.py \
  --revision <full-reviewed-backend-commit> \
  --session /path/to/private-staging-session.json \
  --evidence /path/to/new-rollout-evidence.json

Repeat with --enabled after the separate enabled rollout. The check covers the staging ECS service at observation time. Inventory additional writers separately before enablement; do not roll back to pre-epoch writers after migration begins. Five tests reject mixed revisions, incomplete deployment, wrong digest, an unexpected flag and stopping tasks. Live execution passed at 17:56 UTC: the only running staging task used revision 154 and source 5c82000e, its image matched ECR, and the authenticated API reported migration disabled. Recorded evidence includes the exact digest. Deployment run succeeded. The later enabled rollout at source 433c4cdd, task155, also passed; see the enabled receipt. Inventory examined all 13 running ECS cluster tasks: only the staging service matched its database configuration. The known Terraform EKS cluster contained only system pods; its temporary inspection tunnel was closed. The new tenant-bound test key and exact runtime grant are recorded in the runnable Terraform example. No migration calls were made before this gate. The isolated AWS migration acceptance below followed this gate; production promotion remains separate.

Related documentation: Migration contract describes durable batches and recovery. KMS development note records merged source and validation. Operator setup describes runtime configuration and the deployment gate.

2026-09-13 — owned AWS migration and outage acceptance

Published native CLI 0.17.0 and PyPI 0.14.0 exercised staging 433c4cdd / task155 against a dedicated AWS key. All nine encrypted dependencies (four entries, four write receipts and one HOTP receipt) migrated forward and back to the managed key. A deliberately lost committed response recovered from a fresh CLI process. Revoking only the fixture's runtime grant produced read/resume 503 responses without advancing the checkpoint; restoring the grant recovered access. All four synthetic entries were retired and returned read404. The historical key remains enabled for retention review, not destroyed.

Reviewed evidence PR31 records exact source, artifact hashes, operation times and cleanup. The human-run procedure pairs CLI/Python migration and recovery commands with the Terraform setup. This proves this owned staging AWS flow, not production promotion, second-tenant or wrong-context denial, receipt-only/binding-reference live coverage, cross-provider migration, GCP acceptance or backup erasure. Those gates stay open in master #247 and Vault #241.

2026-09-13 — rollback-alarm preflight (unreleased)

The read-only rollout verifier now requires configured ECS rollback alarms to be observed OK, both before API verification and after refreshing service configuration. Missing, disabled, unreadable or non-OK alarms prevent a readiness receipt, even when tasks are healthy. Eleven local tests cover state transitions and redacted evidence. No cloud configuration changes are included.

Run expected4xx/5xx acceptance checks separately from deployment. Retired-entry404 cleanup samples can affect the managed error-rate alarm; wait for its observed recovery and rerun the gate before deployment. Do not reset, disable, retune or flood the alarm. The task156 flag-only rollback followed such cleanup samples while task155 remained healthy. Sequencing guide and tests. Earlier task154/task155 evidence retains its original scope; it did not verify alarms.