net-kingdom/docs/security-bootstrap-user-lifecycle.md

Security Bootstrap User Lifecycle

Status: draft UX contract Date: 2026-05-24

Purpose

This document defines the first guided user lifecycle flows for the security bootstrap experience. It is the product contract for NET-WP-0016-T04.

The goal is to make common access operations clear without granting platform root by accident.

Actor Classes

Class	Meaning	Root risk
Setup operator	Can assemble or observe early infrastructure	Must not imply root custody
Platform admin	Day-to-day delegated platform administration	Scoped and revocable
Tenant admin	Admin for one tenant or fabric	No platform root
Reviewer	Read-only inspection and audit role	No secret reads by default
Workload principal	Service account or automation identity	Least privilege
King credential	Rare platform-root custody	Break-glass only

The UI must always distinguish actor class before granting access.

Onboard User

Inputs:

• display name;
• contact address;
• actor class;
• tenant or fabric scope;
• requested groups/roles;
• MFA requirement;
• review date.

Flow:

1. Select actor class.
2. Select scope.
3. Show effective privileges before creation.
4. Highlight any platform-admin or root-adjacent role.
5. Require MFA for privileged roles.
6. Create or prepare identity in the selected IAM provider.
7. Record non-secret audit event.

Blocked conditions:

• actor class is missing;
• scope is missing for tenant/fabric roles;
• privileged role without MFA;
• ordinary onboarding tries to grant king custody.

Temporarily Lock User

Purpose: suspend access without deleting identity history.

Flow:

1. Select user.
2. Show active groups, roles, sessions, keys, tokens, and owned resources where available.
3. Disable login or token issuance.
4. Revoke active sessions and short-lived tokens where supported.
5. Preserve audit subject and ownership records.
6. Record unlock instructions and review date.

The UI should label this as reversible.

Permanently Lock And Offboard User

Purpose: remove operational access while preserving audit evidence.

Flow:

1. Select user.
2. Require reason and effective date.
3. Transfer owned resources or service principals.
4. Revoke sessions, tokens, app passwords, SSH keys, and OpenBao tokens.
5. Remove groups, roles, and tenant memberships.
6. Schedule rotation for shared material the user may have seen.
7. Record non-secret offboarding evidence.

Platform-admin offboarding requires a second confirmation. King credential offboarding is not a normal lifecycle action; it is a custody replacement ceremony.

Review And Change Credentials

Purpose: inspect posture and rotate safely.

The review screen should show:

• MFA state;
• recovery confirmation age;
• SSH keys;
• active tokens;
• group and role memberships;
• last review date;
• owned service principals; and
• rotation recommendations.

Actions:

Action	Meaning
Rotate credential	Replace a secret or key
Reset credential	Emergency replacement
Change authorization	Add/remove roles or groups
Schedule review	Set next review date

The UI must keep rotation separate from authorization changes.

New Fabric With Its Own Admin

Purpose: create a fabric with delegated administration but no platform-root authority.

Flow:

1. Name the fabric.
2. Assign fabric admin.
3. Create IAM scope and group mapping.
4. Create OpenBao path prefix and policy request.
5. Define audit and backup expectations.
6. Produce a handover checklist.
7. Record non-secret progress event.

Blocked conditions:

• fabric admin missing;
• platform-root role requested;
• no OpenBao path prefix;
• no review date.

UX Rules

• Show effective access before saving.
• Use plain labels: "locked", "offboarded", "needs review".
• Do not use red/yellow/green as the only indicator.
• Do not display secret values.
• Do not send secrets by email.
• Keep every high-risk action reversible where possible, or explain why it is not reversible.