coulomb/railiance-platform
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat: admit and exercise KeyCape verifier custody activation
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-5.6-luna
Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
This commit is contained in:
codex 2026-09-09 01:32:45 +02:00
parent 52b24eab9a
commit b7861de20e
8 changed files with 662 additions and 184 deletions
Download patch file Download diff file Expand all files Collapse all files

33
docs/credential-lane-designs/keycape-approval-clients-review.md
View file

@ -1,21 +1,22 @@
# KeyCape approval-client custody: review packet
Prepared 2026-09-09 by the-custodian. Both requests are **proposed**; no named
approval or custody mutation has been recorded. This is the review gate for
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 | Pending decision |
| 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 require **platform-operator and key-cape-owner** review. Each has its own
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 object would authorize verifier-side custody only. Client-side
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.
@ -29,14 +30,16 @@ 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 generated
plan leaves initial secret provisioning to the contained owner procedure; it is
not an already exercised end-to-end activation command. Finish and exercise that
procedure before opening the activation window. Current proposed requests refuse
`apply-plan`; no status has been changed to get around that refusal.
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.
Review outcome: approve, deny or needs changes, naming the reviewer and the role
they are accepting. Both required role confirmations must be recorded for each
CCR before execution. A generic CLI status change alone is insufficient evidence
that both reviews occurred. No owner messages or browser login were triggered
by preparation of this packet.
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.

36
docs/evidence/2026-09-09-keycape-approval-admission.json Normal file
View file

@ -0,0 +1,36 @@
{
"schema": "railiance.keycape-custody-user-approval.v1",
"recorded_at": "2026-09-08T23:05:19.886216+00:00",
"user_response": "I approve, go on.",
"approved_question": "Do you approve CCR-2026-0017 and CCR-2026-0018, as platform operator and KeyCape owner, for the verifier-side credential delivery described in the review packet?",
"review_packet_revision": "52b24eab9a8aff3396e71b2296d0240a44f3b0db",
"roles": [
"platform-operator",
"key-cape-owner"
],
"scope": "Two verifier-side KeyCape client credential custody requests, including their governed attended provisioning and compatible rollout sequence.",
"client_side_read_authorized": false,
"factory_spending_authorized": false,
"requests": [
{
"id": "CCR-2026-0017",
"decision_id": "b533a271-b704-4c5c-98a2-9a5951aadfb6",
"status": "approved",
"decision_status": "resolved",
"reviewed_roles": [
"platform-operator",
"key-cape-owner"
]
},
{
"id": "CCR-2026-0018",
"decision_id": "efa90517-0cae-4eb6-a68d-5b0489c84d65",
"status": "approved",
"decision_status": "resolved",
"reviewed_roles": [
"platform-operator",
"key-cape-owner"
]
}
]
}