coulomb/the-custodian
4
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

docs: record completed factory verifier identity milestone
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source
This commit is contained in:
codex 2026-09-09 02:30:11 +02:00
parent cc0badb64b
commit b14cbf2a8b
2 changed files with 189 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

52
docs/assessments/2026-09-09-helixforge-verifier-admission.md Normal file
View file

@ -0,0 +1,52 @@
# HelixForge: verifier identity milestone accepted
The approved CCR-2026-0017/0018 rollout is complete. Both credential requests
are verified, and KEY-WP-0013-T02 is done. The factory programme remains active;
this closes its verifier identity prerequisite.
Two independent version-1 credentials now reach KeyCape through their approved
OpenBao policies, Kubernetes roles and ESO stores. Both stores are Valid and
both ExternalSecrets are SecretSynced. The pinned KeyCape image has one ready
replica. Both service clients passed live signature, exact claim and 900-second
lifetime checks, wrong-secret rejection and excess-scope denial. Existing human
OpenBao login passed before and after replacement. Attended sessions self-revoked.
Native custody checks proved sibling-path and parent-listing denial, wrong
service-account and namespace rejection, outside-namespace store refusal,
reader revocation and coding-agent deny precedence. The signing key and unrelated
configuration bytes were preserved. No credential value entered Git or Hub records.
The work removes recurring manual steps: named reviews are recorded once;
provisioning, verification and recovery are executable; a failed rollout can
resume without regenerating credentials. Failed attempts exercised compatible
configuration/image rollback and exposed three verification assumptions that
are now corrected: containerd manifest identity, verifier execution location,
and small clock differences. The workstation also needs its explicit Railiance
kubeconfig. These are observed improvements to the procedure, not measured
staff-hour savings or evidence of sustained factory throughput.
Validation comprises 71 automated tests, a disposable pinned-image HTTPS exercise
running the exact native verifier, live custody/client checks and a fresh human
login. Future issued-at timestamps use KeyCape's existing 30-second bound;
expiry and not-before remain strict. Initial provisioning did not exercise
natural JWT expiry or actual predecessor rotation.
The next critical-path records are:
1. RPF-WP-0035-T05: separate client-side credential admission and delivery.
2. AUDIT-WP-0009-T09 and APPROVAL-WP-0002: audit custody, deployed approval
startup and real claim/consume acceptance.
3. SECRETS-WP-0009-T03: native credential delivery with expiry/revocation proof.
4. HFACT-WP-0001-T01/T04/T05: exact factory actor/profile/grants and spend contract,
Railiance placement, then natural worker lifecycle and recovery proof.
KEY-WP-0013-T05 retains the separate approval UI callback/MFA requirement.
HFACT-WP-0001-T02 retains the known projection-field and idempotency defects;
successful synchronization here does not fix those systemic issues. No paid
factory execution or fourteen-day observation has started. Reuse-surface remains
the first internal capability, Railiance Fabric the subsequent integration option,
and vergabe-teilnahme the primary customer product repository.
Authoritative evidence: [accepted verifier receipt](/home/worsch/net-kingdom/docs/evidence/2026-09-09-keycape-verifier-admission.json),
[owner rollout and recovery](/home/worsch/net-kingdom/docs/keycape-approval-clients-rollout.md),
and [current factory admission sequence](/home/worsch/prj-helixforge-factory/operations/identity-admission.md).