b7861de20e
Assistant: codex Assistant-Model: gpt-5.6-luna Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
45 lines
3.3 KiB
Markdown
45 lines
3.3 KiB
Markdown
# KeyCape approval-client custody: review packet
|
|
|
|
Prepared 2026-09-09 by the-custodian. Both requests are **approved** by the user as platform operator and KeyCape
|
|
owner, explicitly recorded on 2026-09-09. The admission receipt is
|
|
[here](../evidence/2026-09-09-keycape-approval-admission.json). This is the review record for
|
|
RPF-WP-0035-T05, consumed by HFACT-WP-0001-T03.
|
|
|
|
| Request | Secret path and field | Client authority | Resolved decision |
|
|
| --- | --- | --- | --- |
|
|
| [CCR-2026-0017](../../credential-change-requests/CCR-2026-0017-keycape-secrets-engine-approval-client.yaml) | `platform/workloads/secrets-engine/approval-client`, `CLIENT_SECRET` | `approval:read`, `approval:consume` | `b533a271-b704-4c5c-98a2-9a5951aadfb6` |
|
|
| [CCR-2026-0018](../../credential-change-requests/CCR-2026-0018-keycape-approval-engine-operator-client.yaml) | `platform/workloads/approval-engine/operator-client`, `CLIENT_SECRET` | create/read/approve/revoke/supersede/observe/emit; no consume | `efa90517-0cae-4eb6-a68d-5b0489c84d65` |
|
|
|
|
Both named **platform-operator and key-cape-owner** reviews are approved. Each has its own
|
|
exact-path policy, Kubernetes auth role and ClusterSecretStore, bound to
|
|
`external-secrets/external-secrets`, limited to `sso`. ESO owns the resulting
|
|
Secret; authentication tokens have a 15-minute TTL. Client secrets require
|
|
explicit rotation or registration disablement; token expiry does not revoke them.
|
|
|
|
The approved requests authorize verifier-side custody only. Client-side
|
|
retrieval, audit sender/receiver custody, operator `approval:consume`, adoption
|
|
of the Qonto Secret and factory spending remain outside these two requests.
|
|
|
|
Technical review completed: both CCRs validate, their generated policies match
|
|
the two source HCL files, and the delivery manifests map exactly to the declared
|
|
paths and fields. The signed upstream issuer is verified; NetKingdom's exact live
|
|
pin is independently read back at Secret revision `58713343`. The compatible
|
|
KeyCape image and rollout patch are prepared. These checks are evidence for the
|
|
review, not substitutes for either named approval.
|
|
|
|
Execution still follows the [owner rollout sequence](keycape-approval-clients.md)
|
|
through the founder-attended Warden/OpenBao envelope: policy/roles, CAS=0 initial
|
|
custody, Valid stores, SecretSynced delivery, compatible config/image replacement,
|
|
then positive and negative acceptance and metadata-only receipts. The contained owner command is now `scripts/keycape_approval_custody.py activate`.
|
|
It preflights both config and deployment changes, seeds with CAS=0, verifies native
|
|
and namespace boundaries, then calls NetKingdom's contained compatible rollout.
|
|
A failure restores the prior config/image pair before detaching verifier delivery;
|
|
initial KV versions remain in custody. The four new exact data/metadata deny
|
|
stanzas extend the coding-agent boundary without changing any grant.
|
|
|
|
Validation: six checks against a disposable local OpenBao, eight config/rollback
|
|
tests, and real HTTP signature/claim/scope acceptance against the pinned KeyCape
|
|
image with synthetic keys. Production in-pod CLI and existing-human-login checks
|
|
remain part of the live window. The image exercise omits the in-pod CLI explicitly.
|
|
Use a unique private receipt and protected owner recovery path; a fresh attended
|
|
login after the rollout establishes the existing human path on the new build.
|