diff --git a/docs/netkingdom-service-identity-review.md b/docs/netkingdom-service-identity-review.md new file mode 100644 index 0000000..287b541 --- /dev/null +++ b/docs/netkingdom-service-identity-review.md @@ -0,0 +1,159 @@ +# Review — NetKingdom Service Identity and Privilege (draft-3) + +Reviewed 2026-10-24 by a Claude Code repository worker for security-canon, on a +request from net-kingdom (hub message 28998f18-9af9-4f73-b47e-92b1b6002c56, +ref net-kingdom b774927). Read-only against +`canon/standards/service-identity-privilege_v0.1.md` sections 2, 3, 4. This is a +documentary owner-scoped review by an agent, not human assent. Vocabulary +(Mode of Authority 0.2.0) and SEC-DSM 1.0.0 are unchanged. + +## A. Mode readings + +| # | Reading | Verdict | Supporting canon | +| --- | --- | --- | --- | +| 1 | Read-only directory bind = `USE @ directory` | CONFIRM | `auth-modes.yaml` USE: "obtain the value this system exists to provide"; a directory exists to answer lookups. OBSERVE is "what is this system doing" (logs, metrics, audit records), knowledge about the system, not value from it. The `OBSERVE` contrast line: reading an invoice is USE, reading telemetry about the invoice service is OBSERVE. | +| 2 | `platform-root` = `SOVEREIGN @ platform`, `BREAK_GLASS` in production; `CONSTRUCT @ platform` only in DEVELOPMENT/TEST | CONFIRM, with two notes | Vocabulary card example `recovery-principal: SOVEREIGN @ identity-realm, activation = BREAK_GLASS`; SOVEREIGN "root-account recovery", "establishing trust roots"; vocabulary 11: `ROOT` is not a mode, say the scope; A5 scope-relative. CONSTRUCT is "authority over the possible future system" and the Environment dimension is "especially significant for CONSTRUCT" (dimensions.yaml); a dev-only CONSTRUCT grant is the canon's own pattern (A2: developer may CONSTRUCT with no production access). Notes below. | +| 3 | Local service admin held by a person = `ADMINISTER @ ` | CONFIRM, with a caveat | Vocabulary 11: `break-glass admin -> ADMINISTER, activation=BREAK_GLASS` (exactly the `ld-admin` shape); ADMINISTER typical actions: create users, assign roles, manage groups. Caveat below on GOVERN. | +| 4 | `admin` = `OPERATE @ platform` and `OPERATE @ backup-system` | CONFIRM | Vocabulary 11 and vocabulary card: `backup operator -> OPERATE @ backup-system`; OPERATE typical actions include restore, restart, scale, fail over. Not a ladder (A2): OPERATE does not imply ADMINISTER, so the separate `ADMINISTER @ directory` grant in section 3 is correctly stated. | +| 5 | Break-glass is an activation, not an identity kind; old classes mapped onto `principal_type` and grants | CONFIRM | Vocabulary 11 and `auth-modes.yaml` `not_auth_modes`: `BREAK_GLASS -> any mode with activation=BREAK_GLASS`; Activation dimension value list; `AGENT -> any mode with principal_type=AGENT`; `AUTOMATION -> principal_type WORKLOAD or CONTROLLER`; `SUPERADMIN`/`ROOT` are scoped modes. Principal type must not be encoded in the mode taxonomy, which section 2 respects. | + +### Notes on reading 2 + +1. Environment value. Section 3 gives `platform-root` environment `RECOVERY` + while section 4 SI-6 and section 10 say "in production". The canon has both + `PRODUCTION` and `RECOVERY` as Environment values and `RECOVERY` also as an + Activation value; it does not say which environment a break-glass use of + production is. The direct expression of "break-glass use on the production + platform" is `activation = BREAK_GLASS`, `environment = PRODUCTION`. Using + `RECOVERY` as the environment is permitted but is a NetKingdom convention the + canon neither endorses nor forbids. Open question OQ-1. +2. One principal holding `SOVEREIGN @ platform` and `CONSTRUCT @ platform`. The + canon flags GOVERN plus CONSTRUCT over one scope as a finding (10.1); it is + silent on SOVEREIGN plus CONSTRUCT. NetKingdom separates them by + environment, which is sound under A1/A2; keep the two grants as separate + entries with their own environment, as section 3 does. Open question OQ-2 + (should the canon say so). +3. A5: `SOVEREIGN @ platform` does not imply sovereignty over realms inside it + (OpenBao, LLDAP, the identity realm). Name `platform` as an Authority Realm in + the declarations if recovery of a nested realm is meant. + +### Caveat on reading 3 + +The `GOVERN` test is "can this actor decide what another administrator is +allowed to decide". A local super-admin of a service with a single admin tier +(privacyIDEA, exception SI-X5) can usually also edit the policies that bound +other admins, which is GOVERN-like. The reading stays `ADMINISTER @ service`; +the declaration should add `GOVERN @ ` where the account really holds +that. Not a disagreement, an advisory. Related: `ld-admin` as the LLDAP +super-admin that can reset every credential is arguably also the service's local +recovery authority; the canon's answer is a separate `SOVEREIGN @ lldap` grant +only if the account is used to re-establish the regime. NetKingdom's +sealed-fallback use fits `ADMINISTER` plus `BREAK_GLASS`. + +## B. Other canon readings found in sections 1 to 3 + +- Section 1 says `principal_type` is "InfoTechCanon, via SecurityCanon". The + canon says otherwise: `dimensions.yaml` calls PrincipalType "SecurityCanon's + own classification of the imported ITC-ACCESS Principal" (corrected + 2026-09-20), while the vocabulary table says "InfoTechCanon identity model; + imported". The canon is itself inconsistent here and open as SECURITY-IN-0001. + Section 10 repeats "InfoTechCanon ... owns `principal_type`". Suggest saying: + "`principal_type` as classified by SecurityCanon over the InfoTechCanon + Principal". +- `Environment` is listed as SecurityCanon-owned in the vocabulary table and as + owned by `InfoTechCanonLandscapeModel` in `dimensions.yaml`. Cite as "Mode of + Authority dimension" without naming an owner. +- Section 2 field names: the canon uses `authority_context` and `relation` + (DELEGATED, IMPERSONATED); `provenance` also has DELEGATED and IMPERSONATED + values. The agent convention (`relation = DELEGATED` plus the person as + authority context) is consistent with vocabulary 9. Evidence values are + `target-audited`, `external-audited`, `substrate-audited`, + `multi-party-audited`, `outside-audit-boundary`. +- The activation, environment and relation value lists in section 2 match the + canon exactly. + +## C. SEC-DSM citations (SEC-DSM 1.0.0) + +All cited ids exist (DSM-ID-001, -004; AUTH-001; AP-003, -012, -016, -017; +AUDIT-001, -003; HUM-003; ROOT-001 to -005; INV-002 to -007; STORE-002; +ROT-001, -003; ARCH-002; TRANS-002; AGENT-001 to -008; DX-002; EXC-001 to -004; +section 4.12 Standing Authority). No wrong id. Strength and fit findings: + +1. SI-3, "DSM-ID-001's SHOULD becomes MUST": correct as far as it goes. ID-001 + has a SHOULD (own identifiable runtime identity) and a MUST NOT (production + workloads must not depend on a shared generic credential where individual + identity is practical). Say which sentence is strengthened; the MUST NOT + already covers a bind shared by four services unless impractical. +2. SI-2: DSM-ID-004 has two MUSTs (distinguishable; human credentials not + embedded in automated workloads) and a SHOULD NOT (machine credentials used + interactively). "People and services never share a credential" is stronger + than the rule and the Kubernetes Secret example is NetKingdom's. Fine as an + addition; attribute only the MUST NOT to the canon. SI-3 "never used + interactively" likewise upgrades the SHOULD NOT. +3. SI-1: DSM-AP-003 is an anti-pattern (unrelated workloads share one + production identity), not a rule, and says nothing about principal type. The + human-and-service case is DSM-ID-004. Cite AP-003 as illustration only. +4. SI-4: DSM-AUTH-001 (MUST, least authority) supports "ADMINISTER @ that + service only" but not "one local admin per service" or the naming; those are + NetKingdom's. Same for SI-7: DSM-AP-012 is an anti-pattern (developers + routinely retain production credentials locally), not a MUST. +5. SI-5: DSM-AUDIT-003 is a SHOULD (identify principal, resource, operation, + policy context, time, result, execution identity); section 4.12 is a + statement of objective, not a requirement. "Attributed administration first" + is a NetKingdom MUST resting on a SHOULD; state that. +6. SI-6: HUM-003 (MUST, exceptional, attributable, auditable, time-bounded where + practical) fits. ROOT-001 (MUST), ROOT-003 (MUST NOT), ROOT-004 (MUST) fit; + ROOT-002 and ROOT-005 are SHOULD. "Held offline" and "never a drill's test + subject" are NetKingdom's; ROOT-003 only requires that root credentials not + travel through ordinary application delivery. +7. SI-9: INV-002 is a SHOULD list of attributes; it has no "location" field + (closest are `delivery_method` and `resources`). STORE-002 (SHOULD minimize + copies) does not say "declare". The MUST that fits "every credential is in + the inventory" is DSM-INV-001 (MUST maintain an inventory of + security-significant persistent credentials). Suggest citing INV-001 and + noting declaring storage places is NetKingdom's addition. +8. SI-10: INV-003, ROT-001, ARCH-002 and TRANS-002 are MUST and fit. ROT-003 + (MUST NOT consider complete until adopted) is the basis of "coupling"; + "declare the coupling" is NetKingdom's. Correct. +9. SI-11: INV-005 (SHOULD distinguish declared, discovered, verified, inferred, + unknown) and INV-006 (MUST treat a discovered, unowned production credential + as a finding) fit; INV-007 is a SHOULD. Note INV-006 triggers on an + unowned credential; "declared or it is a finding" for every account is + stricter. The five evidence states are in INV-005, while `unknown` as a + conformance result is NetKingdom's. +10. SI-12: ROOT-001 and ROOT-004 are MUST and fit. "Works with SSO and OpenBao + down" is NetKingdom's. +11. SI-14: AGENT-001 (MUST), -004 (MUST NOT), -006 (MUST), -007 (MUST NOT) and + -008 (MUST) fit as cited; -002, -003, -005 are SHOULD. DSM-AGENT-001 speaks + of "distinguishable workload identities", so DSM treats an agent as a kind + of workload identity while the vocabulary has a separate AGENT + principal_type; the SI-14 mapping to `AGENT` is a reasonable reading but is + NetKingdom's. DSM-AGENT-003 is SHOULD; the 60-minute ceiling is + NetKingdom's. AP-016 and AP-017 fit. +12. SI-15: DSM-AUDIT-001 binds "the secrets or capability authority", not every + state-changing action of an agent or workload; it does not support "every + action is reconstructable". AUDIT-003 is a SHOULD. DSM-DX-002 (SHOULD + provide reusable integrations: CI templates, modules, SDK helpers) says + nothing of a prepare, admit, execute, verify, retain path; the golden path + is NetKingdom's, and DX-002 is only the generic basis for having one. +13. Section 8: DSM-EXC-002 MUST records "elimination path or review trigger"; + EXC-004 (SHOULD) says state what event removes the debt. Section 8 says + exceptions "carry an elimination path": stricter than EXC-002 (which allows + a review trigger instead) and consistent with EXC-004. DSM-EXC-001 binds + only violations of a MUST; an exception against a SHOULD-derived NetKingdom + rule is NetKingdom's own. +14. Section 7: DSM-INV-004 is a SHOULD ("where practical"); "MUST NOT read a + Secret" is NetKingdom's and compatible with DSM-AUDIT-002. + +## D. Open questions for security-canon (recorded as SECURITY-IN-0002) + +- OQ-1: Environment of a break-glass use of production: `PRODUCTION` plus + `activation = BREAK_GLASS`, or the `RECOVERY` environment? Canon guidance + absent. +- OQ-2: May one actor hold SOVEREIGN and CONSTRUCT over one scope, separated by + environment? Canon names only the GOVERN plus CONSTRUCT finding (10.1). +- OQ-3: Is a sealed offline credential (`platform-root`) a principal of type + `HUMAN`, or a credential held by a human? Canon has no concept of a + credential-without-principal; SI-6 treats it as a `HUMAN` grant. +- OQ-4: The ownership wording of `principal_type` and `Environment` + (see section B); folds into SECURITY-IN-0001. diff --git a/intakes/intakes.md b/intakes/intakes.md index 708a9e0..eae1c8e 100644 --- a/intakes/intakes.md +++ b/intakes/intakes.md @@ -26,3 +26,27 @@ description: >- before changed guidance is distributed. Evidence: docs/emergent-knowledge-021-review.md. state_hub_intake_id: "01a10268-944f-7ce2-a166-7c4a1fc8260a" ``` + +## SECURITY-IN-0002 — Mode of Authority guidance for NetKingdom estate profile + +```yaml +id: SECURITY-IN-0002 +kind: intake +title: Mode of Authority guidance for NetKingdom estate profile +status: open +origin: request +origin_ref: hub message 28998f18-9af9-4f73-b47e-92b1b6002c56 (net-kingdom b774927) +priority: low +owner: security-canon +requested_by: net-kingdom +created: '2026-10-24' +updated: '2026-10-24' +description: >- + docs/netkingdom-service-identity-review.md confirms NetKingdom's five mode + readings and lists SEC-DSM citation corrections. Four canon questions have no + guidance: environment of a break-glass use of production (PRODUCTION vs + RECOVERY), SOVEREIGN plus CONSTRUCT held by one actor, principal of a sealed + offline credential, and ownership wording of principal_type and Environment + (fold into SECURITY-IN-0001). Docs only; no vocabulary or SEC-DSM change is + made by this intake. +``` diff --git a/workplans/ADHOC-2026-10-24.md b/workplans/ADHOC-2026-10-24.md new file mode 100644 index 0000000..30a96eb --- /dev/null +++ b/workplans/ADHOC-2026-10-24.md @@ -0,0 +1,26 @@ +--- +id: SECURITY-WP-ADHOC-2026-10-24 +type: workplan +title: "Review NetKingdom Service Identity and Privilege mode readings" +domain: infotech +repo: security-canon +status: finished +owner: claude-code +topic_slug: security-canon +created: "2026-10-24" +updated: "2026-10-24" +--- + +## Review mode readings and SEC-DSM citations + +```task +id: SECURITY-WP-ADHOC-2026-10-24-T01 +status: done +priority: low +``` + +Evidence: docs/netkingdom-service-identity-review.md. Owner-scoped documentary +review by an agent for net-kingdom (hub message 28998f18). All five mode readings +confirmed with notes; SEC-DSM citation fit findings listed; open questions in +SECURITY-IN-0002. No vocabulary, SEC-DSM, policy or runtime change; no human +assent asserted.