3.2 KiB
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:
- RPF-WP-0035-T05: separate client-side credential admission and delivery.
- AUDIT-WP-0009-T09 and APPROVAL-WP-0002: audit custody, deployed approval startup and real claim/consume acceptance.
- SECRETS-WP-0009-T03: native credential delivery with expiry/revocation proof.
- 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, owner rollout and recovery, and current factory admission sequence.