36 of 37 CCRs are already workload-kv-read; browser and service OIDC clients and forge read identities follow. Ranking and recommendation recorded. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 5457@bnt-lap001 Assistant-Session: 792bf84a-3783-4f5d-a811-cded61dd2012
4.8 KiB
SecurityCaseType inventory — NK-WP-0048-T02
Read-only survey, 2026-10-08, of the security integrations built so far, grouped
by shape, as candidates for SecurityCaseTypes (canon
security-case-types_v0.1, proposed). Sources: railiance-platform
credential-change-requests/ (37 CCRs) and docs/credential-lane-designs/
(22 designs); ops-warden registry/routing/catalog.yaml (41 entries); key-cape
config/service-clients.example.yaml; net-kingdom
sso-mfa/k8s/keycape/*-rollout.py and register-*.py; ops-mason workplans. No
secret values were read.
Ranking
| Rank | Candidate type | Instances today | Manual cost per instance today | Recommendation |
|---|---|---|---|---|
| 1 | workload-kv-read | 36 of 37 CCRs (request_type: workload-kv-read) |
a full CCR: request, review, founder confirmation items, OpenBao policy and OIDC role, catalog entry, verification | the strongest candidate: the most repeated shape, and it already has a CCR schema with risk, rollback and verification fields |
| 2 | oidc-browser-relying-party | informed-decision-approver, coulomb-social, user-engine portal, vergabe, openbao-admin; Forgejo pending | a new rollout script and test in net-kingdom sso-mfa/k8s/keycape/ per client, plus an attended founder run |
first type per NK-WP-0048-T04 (it unblocks the forge closure) |
| 3 | oidc-service-client (confidential, client_credentials) |
codex-railiance-platform, secrets-engine-openbao, -approval, -requester, approval-engine-operator, informed-decision-sitting-requester | a key-cape registration script, plus two or three workload-kv-read CCRs per client (verifier custody, client-side reader, attended operator reader; for example CCR-0017/0019, 0018/0020, 0024/0025, 0026/0027, 0033/0034), plus an ops-mason plan (MASON-WP-0009) | compose from types 1 and 2's registration capability, not separately |
| 4 | forge-read-identity | CCR-0014 (policy-nexus), CCR-0031 (core-hub repo-manager), lane designs activity-core-repo-manager-forgejo-read, core-hub-forgejo-source-read; CCR-0006 Forgejo admin token |
a workload-kv-read CCR plus a hand-made Forgejo token | needed in bulk by ORGREF-WP-0002-T06: ArgoCD, k3s registry pull, CI tokens, reuse-surface and code readers (inventory there: 43 workloads, 10 Applications, about 20 CI repos) |
| 5 | eso-delivery (Kubernetes auth to ExternalSecret) | core-hub forgejo source, activity-core backup offsite, Authelia SMTP projection (CCR-0035) | Kubernetes auth role, ClusterSecretStore and ExternalSecret per consumer | a delivery variant of type 1; a parameter, not a separate type |
| 6 | attended-host-key-delivery | CCR-0028 (Railiance Clock signing key, mode 0600 on host); node-delivery readers CCR-0036/0037 | attended host write | small; keep as cases of type 1 with a host-delivery parameter unless signing keys need their own rules |
| 7 | signing-identity | CCR-0015 (State Hub preflight signing), CCR-0028, factory audit senders (CCR-0021/0022) | custody and audit wiring per sender | review once types 1 and 3 exist |
| 8 | ssh-certificate | ops-warden warden sign (adm, agt, atm) |
already a working pattern | adopt as a type by documenting it; little new build |
| 9 | operator attended login | ops-warden login and ceremony lanes (OpenBao platform admin, scoped operator OIDC) |
the contained login envelope | a building block that types reference for attended steps, not a case type |
Observations
- The CCR is already a SecurityCase in all but name. Each one carries risk,
rollback, verification, lifecycle and founder-confirmation items. What is
missing is the type behind it: today every CCR is reviewed as if its shape
were new. Formalizing
workload-kv-readas a type would turn most of the 36 into light cases. - Clients come in compositions. A confidential service client today needs a key-cape registration plus two or three KV-read CCRs. A type for it should compose those, not repeat them.
- Browser clients are cheap to formalize. The per-client rollout scripts already share a pattern (non-exporting Secret merge, inspect, dry-run, apply, remove, tests); key-cape's playbook capability can generalize it once.
- Attended steps cluster. Most manual founder time goes into OpenBao logins and live key-cape configuration writes. Types should name these steps explicitly, so that ops-warden can batch them into one attended session per run.
Recommendation for NK-WP-0048
Keep oidc-browser-relying-party as the first type, because it unblocks
KEY-WP-0038 and the forge closure. Make workload-kv-read the second type,
since it has the largest payoff, then forge-read-identity as a
parameterization of it for ORGREF-WP-0002-T06, followed by the confidential
service client as a composition. The founder may prefer to swap the first two;
that is a sequencing choice, not a design one.