coulomb/net-kingdom
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

bootstrapping guidance ui and missing stuff

Browse Source
This commit is contained in:
Bernd Worsch
2026-05-24 17:04:15 +02:00
parent 1d0b0e7330
commit d555a33695
10 changed files with 913 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
docs/platform-root-custody.md
View File

@@ -76,6 +76,54 @@ break-glass material. The preferred end state is:
- Routine access flows through NetKingdom IAM claims and scoped OpenBao
policies.
## Where The King Credential Lives
The king credential is an identity and custody record, not an OpenBao password.
In the current lightweight NetKingdom stack, the practical placement is:
| Part | Current home | Notes |
| --- | --- | --- |
| User record | LLDAP | dedicated `platform-root` or `king` user, separate from `tegwick` |
| Password login | Authelia over LLDAP | day-to-day email is notification-only |
| TOTP / token enrollment | privacyIDEA | QR/setup key comes from privacyIDEA self-service |
| privacyIDEA administration | `pi-admin` | setup and repair account, not the king credential |
| IAM Profile / OIDC token | KeyCape | target issuer for normal platform identity claims |
| Secret custody and audit | OpenBao | initialized after custody approval; not the human identity provider |
OpenBao enters the story after custody approval: it holds platform secrets,
unseal/recovery material handling, audit, policies, and temporary or future
admin auth methods. It should not be used as the place where the human king
password or OTP seed lives.
LLDAP deliberately has no public registration flow. The first-user process is
administrator-provisioned:
1. Log in to `https://lldap.coulomb.social` as `admin`.
2. Retrieve `LLDAP_LDAP_USER_PASS` from the operator password safe entry
`net-kingdom/LLDAP/admin`.
3. Create the dedicated `platform-root` or `king` user.
4. Add the user to `net-kingdom-admins` for the current lightweight path.
5. Store the new account password only in the password safe or offline custody
packet.
6. Use `pi-admin` in privacyIDEA to confirm that the LLDAP resolver can see
the new user and that self-enrollment is allowed.
7. Log in to privacyIDEA self-service as `platform-root` and enroll the TOTP
token there. The QR/setup key belongs only in the authenticator and custody
storage, never in this repo, State Hub, chat, or the local control surface.
8. Verify the OIDC login path through a registered KeyCape client. KeyCape is
an issuer, not a dashboard; the root URL may return `404` while discovery,
health, authorize, token, and userinfo endpoints are healthy.
The local control surface records this as non-secret progress: account
reference, group assignment confirmation, password-safe confirmation, and later
login-path verification. It does not read or store the password, OTP seed, QR
code, or recovery codes.
Do not use a successful `platform-admin` login as proof of `platform-root`
custody unless the recorded king credential was intentionally changed to
`platform-admin`. `platform-admin` is the later non-root operator path; it is
useful, but it is not the same as proving the platform-root custody identity.
## Trust Progression
The platform moves through explicit trust stages: