feat: verify live KeyCape custody and preserve versions on resume
Assistant: codex Assistant-Model: gpt-5.6-luna Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
This commit is contained in:
parent
b7861de20e
commit
c6dc4286e2
8 changed files with 382 additions and 57 deletions
|
|
@ -1,14 +1,20 @@
|
|||
# KeyCape approval-engine client custody admission
|
||||
|
||||
**2026-09-09 accepted:** verifier custody and the compatible image/config are live;
|
||||
both service verifiers and a fresh existing-human OpenBao login passed. Both CCRs
|
||||
are verified. [Live evidence](../evidence/2026-09-09-keycape-verifier-admission.json) supersedes the preparation
|
||||
status below. Client-side reads and factory operating grants remain separate.
|
||||
|
||||
Answer to KEY-WP-0013-T02 (State Hub message
|
||||
`278a3ebe-b529-49f6-bd1a-e3ebcf318260`, KeyCape packet
|
||||
`key-cape: docs/approval-engine-provisioning-request.yaml`). Tracked here as
|
||||
RPF-WP-0035-T05. Requests: [CCR-2026-0017](../../credential-change-requests/CCR-2026-0017-keycape-secrets-engine-approval-client.yaml),
|
||||
[CCR-2026-0018](../../credential-change-requests/CCR-2026-0018-keycape-approval-engine-operator-client.yaml).
|
||||
|
||||
Nothing below is an activation. Both CCRs are `proposed`; no value has been
|
||||
generated, no KV version written, no manifest applied. Source preparation is not
|
||||
live completion.
|
||||
Both CCRs are **verified** following explicit user approval in both reviewer
|
||||
roles. Version-1 custody, ESO delivery, the compatible KeyCape rollout and the
|
||||
fresh existing-human login all passed. The contract below defines the completed
|
||||
verifier-side scope; client-side reads remain a separate admission.
|
||||
|
||||
## a) Custody paths and field names
|
||||
|
||||
|
|
@ -53,7 +59,7 @@ keycape-rapp-qonto-client, key: client-secret}`. Read-only observation
|
|||
2026-09-08, and it confirms KeyCape's own statement that the image carries only
|
||||
that one client reference.
|
||||
|
||||
Manifests are written and client-validated but unapplied:
|
||||
Both delivery manifests are applied and live-verified:
|
||||
`argocd/platform-addons/openbao-secretstore/openbao-keycape-approval-clients.clustersecretstore.yaml`
|
||||
and `keycape-approval-clients.externalsecrets.yaml`.
|
||||
|
||||
|
|
@ -146,9 +152,10 @@ ExternalSecrets, detach the policies from the roles. The KV versions are retaine
|
|||
until KeyCape confirms whether the registrations stay; if they are abandoned,
|
||||
KeyCape disables the registrations first and platform then destroys the versions.
|
||||
|
||||
**Date is not set here.** It depends on the founder's availability, which is not
|
||||
mine to schedule. Propose a slot from 2026-09-10 and I will confirm the
|
||||
platform side; the window needs roughly 60–90 minutes with both owners present.
|
||||
The attended window completed on **2026-09-09** under the user's explicit
|
||||
approval. Failed checks restored the compatible config/image and detached ESO
|
||||
delivery. The final resume preserved both initial KV versions and passed all
|
||||
service checks plus a fresh existing-human OpenBao login.
|
||||
|
||||
## What is not admitted
|
||||
|
||||
|
|
@ -184,4 +191,4 @@ approval is performed by this preflight.
|
|||
|
||||
2026-09-09: the live issuer pin is complete. The next review is captured in
|
||||
[keycape-approval-clients-review.md](keycape-approval-clients-review.md), with
|
||||
one pending Hub decision per existing CCR and both required reviewer roles.
|
||||
the resolved Hub decisions, both recorded reviewer roles and completed live verification.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue