Operator Accounts

Who administers the server, with a name: operator accounts are the admin console's identity, separate by design from the API keys that callers use. Each operator signs in as themselves, holds a role that bounds what they may change, carries their own second factor, and leaves an attributable trail. For the person who owns the deployment and the reviewer who asks "who can do what, and how would you know".

1One account per human#

The admin console authenticates OPERATORS, never API keys: the two credential populations serve different doors, and neither opens the other (The Security Model draws the full boundary). Create one account per human in Access: shared passwords cannot be revoked for one person, cannot carry per-person second factors, and turn the security trail into a guess. With named accounts, every sign-in, configuration change, credential edit, and second-factor event lands in the trail with the actor on it.

2Three roles#

Give the first Owner a deputy: a second Owner account is the cheapest insurance against a locked-out sole administrator.

3The first operator, and break-glass#

Three ways in, in the order deployments meet them:

• First start: while NO operator account exists, the admin surface is open from the local machine so the first visit can create the first account. Seeding Admin__InitialPassword through the environment creates the local admin account with that password instead; the value applies only while no account exists and is never stored in plain text.
• Day to day: Owners create, disable, and delete accounts in Access.
• Break-glass: lmkit admin on the host acts on the identity store directly, no sign-in required: create-owner mints a new Owner, reset-password (with --one-time to force a change at next sign-in) recovers a locked-out human, list shows the accounts. Host access IS the credential here, which is exactly the property that makes it break-glass.

4Second factors#

Each operator enrolls their own authenticator (TOTP) from the console and receives eight recovery codes, shown exactly once and usable once each. Sign-in throttling and per-account lockout slow guessing regardless. To make enrollment mandatory, set Security:RequireTwoFactor: it applies live, and the next unenrolled operator to sign in is walked through enrollment before they get a session.

5Where accounts live: the identity store#

Accounts, sessions, second factors, lockout state, and the security trail live in the admin identity store. By default that is an embedded database under the state directory: zero setup, right for one server. Pointing Admin:Identity at a dedicated PostgreSQL, MySQL, or SQL Server database makes the whole admin domain span every server that shares it: one account set, sessions and revocations honored everywhere within seconds, API keys and stored responses domain-wide, one security trail. That shared store is what lets a load-balanced fleet behave as one installation (Scaling Out).

One law rides this store: identity and document content never share a database. The identity store refuses to land in a knowledge-base database and the reverse, so the blast radius of each credential set stays its own.

6Sessions and the trail#

A sign-in mints a session token; sessions are listed and revocable per operator, and a revocation is effective everywhere within its short validation window. The security trail (sign-ins and failures, account lifecycle, credential and second-factor changes) is readable under the audit history's security source, and on a shared identity store it is the domain-wide view across every node.

7Sign-in through your identity provider#

Admin SSO replaces passwords with your IdP for daily sign-in: operators authenticate there, group claims map to the three roles, and the accounts above remain as break-glass (Single Sign-On is the complete setup, including why the break-glass account stays).

8Stated plainly#

• One named account per human; Owner, Admin, and Viewer bound what each may change, and the Owner surfaces are the ones that decide who else gets in.
• Second factors are per operator, with eight one-time recovery codes; Security:RequireTwoFactor makes enrollment a condition of the next sign-in.
• Admin__InitialPassword seeds the first account; lmkit admin on the host is the break-glass; a second Owner is cheaper than either.
• The identity store is embedded for one server and a dedicated shared database for a fleet; identity and document content never share a database.