net-kingdom/workplans/NK-WP-0054-service-identity-policy.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	related	state_hub_workstream_id
NK-WP-0054	workplan	Service identity and privilege policy, conformance check and bind-account split	infotech	net-kingdom	proposed	implementation	claude	netkingdom	2026-10-24	2026-10-24	NK-WP-0049 NK-WP-0053 NK-WP-0031	36f61e43-f1f3-53fc-ad77-d1d797b3d5b1

NK-WP-0054 — Service identity and privilege policy

Intake from the founder's direction on 2026-10-24, during NK-WP-0049 backup validation. Three identities exist today: platform-root (all-mighty build-mode access, not for production use), tegwick (developer) and admin (platform administrator, intended for operations and for backup validation and crisis recovery). Findings that led here:

• The T19 MFA proof ran as platform-root, the identity meant to leave production use.
• The human admin is LLDAP uid=admin, which is also the directory bind account for Authelia and the privacyIDEA resolver. One account has one password, so the human password is the service secret held in Kubernetes Secrets and in every backup bundle. An OTP on admin protects KeyCape logins but not the bind path.
• pi-admin already exists for privacyIDEA and is separate; its credentials are in the founder's personal password safe.
• No concrete crisis custody list existed. A first draft is docs/crisis-custody-list.md.

Direction: dedicated svc-<service> bind accounts, a dedicated admin account per service (ld-admin, pi-admin, …), a NetKingdom standard that governs which identities and privileges may exist for the services that are part of NetKingdom, and a health check that validates conformance. This plan prepares and proposes; it grants nothing and changes no live service. IAM Profile v0.3 already distinguishes human, service and agent principals in tokens; this standard governs the accounts behind them and must extend, not contradict, that profile and Credential Management Standard v0.2.

Inventory current service identities and privileges

id: NK-WP-0054-T01
status: done
priority: high
assignee: claude-code
state_hub_task_id: "422918a5-c695-5fe3-ba3c-2b370b2ef4dc"

Read-only inventory from repository manifests, ConfigMaps and owner-provided metadata. No Secret is read. For each NetKingdom service (LLDAP, Authelia, KeyCape, privacyIDEA, OpenBao, user-engine, tenant-engine, flex-auth and the platform consumers) list every identity: name, class (human, break-glass, service bind, service admin, workload), privileges, the credential's custody location, its consumers and its owner.

Done when: docs/service-identity-inventory.md lists every identity with its source, and states plainly which entries are unknown and who must confirm them.

Completed 2026-10-24. docs/service-identity-inventory.md covers people, LLDAP, Authelia, KeyCape, privacyIDEA, the identity-provisioner and engines, and OpenBao (railiance-platform files read read-only). No Secret or live service was read. It ends with a table of what is unknown and who confirms it. Main finding: the admin credential has five consumers (the human, Authelia, KeyCape, the privacyIDEA resolver and the identity-provisioner), so T05 needs four service accounts, not two. Also recorded: the provisioner needs more than read access, trigger-admin is an uninventoried legacy admin, and OpenBao platform-admin binds on a group claim alone (a question for T02, not a defect).

Draft the Service Identity and Privilege standard

id: NK-WP-0054-T02
status: wait
priority: high
assignee: claude-code
needs_human: true
decision_id: "a3582e79-4ece-4902-9bfa-e962aef2b8f2"
depends_on: [NK-WP-0054-T01]
blocking_reason: "Draft-1 delivered 2026-10-24. Await the founder review and answers to the six open questions in section 10."
state_hub_task_id: "5830e2eb-334a-52fa-9c55-a8c00d89c09f"

Write canon/standards/service-identity-privilege_v0.1.md as a proposed standard: identity classes; naming (svc-<service> for binds, <service>-admin for admins); the rules the founder's findings imply (one identity, one purpose; a bind account is read-only and never a login; no human uses a service credential; humans and admins require MFA; every identity has an owner, a custody class and a rotation path; the break-glass identity is not routine); the exception record; and its relation to IAM Profile v0.3, Credential Management v0.2 and the Security Zones standard.

Done when: the draft is reviewed by the founder and the service owners it names.

Draft-1 delivered 2026-10-24: canon/standards/service-identity-privilege_v0.1.md (proposed). Thirteen rules (SI-1 to SI-13), naming, a target shape for today's services, the declaration fields, the conformance result states, five initial exceptions (SI-X1 to SI-X5) and six open questions. It extends IAM Profile v0.3 and Credential Management v0.2 without changing either. Review is the founder's, then the service owners named in the inventory.

Schema and offline conformance validator

id: NK-WP-0054-T03
status: wait
priority: medium
assignee: claude-code
depends_on: [NK-WP-0054-T02]
blocking_reason: "Needs the reviewed T02 standard."
state_hub_task_id: "a5c51d69-28ff-5458-83eb-10a35c8c5492"

A declaration schema in canon/schemas/ and an offline validator in tools/service-identity/, in the style of tools/tenancy-posture and tools/custody-record: each service declares its identities, the validator checks the declaration against the standard, refuses secret-shaped values and reports counts only.

Done when: valid and invalid fixtures pass and fail as expected, and the declarations for the current services are checked in.

Live conformance health check

id: NK-WP-0054-T04
status: wait
priority: medium
assignee: claude-code
depends_on: [NK-WP-0054-T03]
blocking_reason: "Needs the validator and owner agreement on what read-only metadata each service owner can provide."
state_hub_task_id: "c8db4607-9306-572b-a3cb-c35ca5989ec7"

Compare declared against observed: for example, which DN each consumer's configuration binds as, which group the bind accounts belong to, and which policies the admin roles carry. Observed state comes from owner-provided read-only metadata and repository manifests, never from reading Secrets. Findings feed the existing proposal-only posture feedback (tools/posture-feedback) with an evidence-freshness bound. It changes nothing.

Done when: a dated run reports conformant, non-conformant and unknown per identity, with each owner named for every finding.

Split the directory bind from the human admin

id: NK-WP-0054-T05
status: wait
priority: high
assignee: claude-code
needs_human: true
decision_id: "9f0f7a87-7adb-44f6-8360-db6a80e3ceca"
depends_on: [NK-WP-0054-T01]
blocking_reason: "Production change across LLDAP, Authelia, privacyIDEA and their Secrets; needs the founder's go and the platform owners. The founder runs live Secret and rollout steps."
state_hub_task_id: "c43d339a-fc8a-5526-885a-64693c930005"

Create svc-authelia, svc-keycape and svc-privacyidea as read-only directory binds and a narrowly scoped provisioner account that can create users and groups without being the directory super-admin (the inventory found these four consumers beside the human; the narrowest working privilege for the provisioner must be tested against the pinned LLDAP image first). Switch the Authelia, KeyCape and privacyIDEA resolver configurations and the provisioner to them, make admin's password human-only and rotate it, and remove the shared secret from the service Secrets. Update the backup profile, the restore adapters (isolated-lldap.py, isolated-authelia.py, isolated-privacyidea-mfa.py, which read the directory password from lldap-secrets and rewrite the resolver address) and the restore packet. Prepare guarded helpers and filled-in commands; the founder runs the live steps.

Done when: both services bind with their own read-only accounts, the human admin password is not present in any service Secret, a fresh backup restores and passes the T17 and T19 drills under the new accounts, and the old shared credential is retired.

Disposition of per-service admin accounts

id: NK-WP-0054-T06
status: wait
priority: medium
assignee: claude-code
needs_human: true
decision_id: "9f0f7a87-7adb-44f6-8360-db6a80e3ceca"
depends_on: [NK-WP-0054-T02]
blocking_reason: "Founder decision per service: which dedicated admin account exists, its name and its custody."
state_hub_task_id: "8072b5cf-4161-58b9-8dfc-62fa102ccd16"

For each service decide whether a dedicated admin account exists and what it is called: LLDAP (ld-admin), privacyIDEA (pi-admin, existing), Authelia, KeyCape (client registry), OpenBao (the platform-admin role) and others. Record the result in the inventory and the standard. LLDAP's built-in admin name is configurable but renaming it on an existing directory is untested here, so it needs a rehearsal before any decision.

Done when: every service has a recorded disposition and a custody location.

Maintain the crisis custody list

id: NK-WP-0054-T07
status: todo
priority: high
assignee: claude-code
needs_human: true
decision_id: "9f0f7a87-7adb-44f6-8360-db6a80e3ceca"
blocking_reason: "The founder confirms every TO CONFIRM row in docs/crisis-custody-list.md: share holders, copies of the age key, the crisis path to production, bundle location."
state_hub_task_id: "ae8524ff-12d8-59c2-b46b-88f3bfd44dd8"

Keep docs/crisis-custody-list.md current, and propose a non-secret machine-readable record with a freshness check, modelled on tools/custody-record, so a drill can verify that each row has a holder, a location and a last-proven date.

Done when: no row is marked TO CONFIRM, the freshness check exists and the first admin-operated drill (NK-WP-0053) has verified the list.