net-kingdom/docs/security-case-type-inventory.md
tegwick df15d6900d
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
NK-WP-0048-T02 done: SecurityCaseType inventory
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
2026-10-08 22:21:40 +02:00

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-read as 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.