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 on a server that serves this machine only, the admin surface is open so the first visit can create the first account. A server that starts reachable from the network (Security:NetworkAccess=Network, which every container is) never opens: it creates the local admin account itself with a one-time password, prints that password once in its startup log, and the first sign-in replaces it. Seeding Admin__InitialPassword through the environment creates the local admin account with that password instead, on either posture; the value applies only while no account exists and is never stored in plain text. It is ignored once any account exists. Admin__Password is the emergency reset, not a seed: on EVERY start it is present it overwrites the admin account's password and re-enables the account if it was disabled, then the server scrubs it from its own settings file. A value supplied by the environment, or on a node whose configuration the deployment owns, cannot be scrubbed, and the log names the source still supplying it: set it for one restart, sign in, and remove it, or every restart undoes the next password change.
• 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. The verb resolves the identity store from the invoking shell's configuration and environment, so on a service or container node run it with the node's own environment (the unit's Environment= lines, the container's environment); an interactive shell without Admin__Identity__* provisions a per-node embedded store nobody serves (The Command Line).

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 the 30-second validation window each node caches them for, 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). It is also an availability dependency with a stated contract: the admin surface never opens on a shared store and keeps that posture while the database is unreachable, sign-in, operator management and key management refuse until it returns, and API keys already in a node's 30-second snapshot keep authorizing meanwhile, so inference continues through an outage that the security trail records once.

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.

A single node becomes a farm member without losing an account: an Owner joins from the identity domain card of the Access section (or an operator runs lmkit farm join with the server stopped), the node's operators with their second factors, its API keys with their counters, its stored responses and its signing secret are copied into the shared database, and the node points at that database from its next restart. The join shows the farm's domain key once; every node carries it as LMKIT_DOMAIN_KEY. The step-by-step procedures, the outage runbook and the way back are Farm Runbooks.

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 the validation window section 5 quotes, the time a node trusts a cached session before asking the store again. 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, and a server that starts reachable from the network with no account generates one for admin, printed once in the startup log; lmkit admin on the host is the break-glass, run with the node's environment so it reaches the store the node serves; a second Owner is cheaper than either.
• The identity store is embedded for one server and a dedicated shared database for a fleet, honored everywhere within one validation window and fail-closed while unreachable; identity and document content never share a database.