net-kingdom/docs/security-case-type-inventory.md

51 lines
4.8 KiB
Markdown
Raw Normal View History

# 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.