c6dc4286e2
Assistant: codex Assistant-Model: gpt-5.6-luna Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
1.8 KiB
KeyCape approval-client custody: accepted verifier delivery
Both CCR-2026-0017 and CCR-2026-0018 have the user's explicit approval as platform operator and KeyCape owner. Both are now verified. Their existing decision IDs remain resolved; no renewed review is needed for this completed scope.
Combined live receipt records version-1 custody, both ESO stores and Secrets, exact native scope/auth/namespace denials, reader revocation, compatible pinned KeyCape deployment and both service-client verification runs. The existing human OpenBao login passed before and after the rollout.
The two Warden fetch selectors remain unresolved: these CCRs authorize verifier copies only. Client-side reads, audit custody, natural JWT expiry, real predecessor rotation and factory operating/spend admission remain with the existing owner records. See the owner sequence.
The exercised procedure is scripts/keycape_approval_custody.py: activate for
first provision, resume-activate only with a completed rollback receipt, and
verify for existing custody. The selected kubeconfig must identify railiance01;
on this workstation it is /home/worsch/.kube/config-railiance01. Use the
Warden attended wrapper, a unique metadata receipt and protected recovery file.
The pinned native verifier is extracted from image digest 7ff54c54e63e... and
hash-checked; its child environment carries credentials only during execution.
No Kubernetes egress policy changes are needed.
Validation: eight local OpenBao checks, ten config/rollback/clock checks, 53 existing credential-change tests, plus a disposable pinned-image HTTPS exercise that runs the exact native verifier with synthetic keys and client credentials.