DocsSecurity & governance
Instance administration
Site-admin scope: users, runners, SSO/LDAP, SIEM tokens, security policy, org templates, and audited impersonation.
Scope#
Available only to accounts with isAdmin: true (see Authorization & permissions), under the Admin sidebar entry:
| Area | Capability |
|---|---|
| Users | Search every account instance-wide; deactivate/reactivate; grant or revoke site-admin; impersonate. |
| Runners | View registered services/runner instances, their tags, and last-seen heartbeat. |
| Single sign-on / LDAP | Instance-wide identity provider configuration (in addition to any per-organization SAML config). |
| SIEM export | Issue and revoke khub_siem_... tokens for the pull-based audit export. |
| Security policy | Instance-wide security floors (see Compliance, audit & data governance). |
| Org templates | Define reusable organization shapes (see Templates). |
Impersonation#
An admin can impersonate any user to reproduce a support issue from their exact permission and data context. Impersonation:
- Issues session cookies scoped to the impersonated user, while a separate
khub_impersonatorcookie retains the admin's real identity so the session can be ended and correctly attributed. - Displays a persistent, unmissable banner for the duration — there is no "silent" impersonation mode.
- Is itself an audited action (start and end, with the admin's and target's IDs), and every action taken while impersonating is recorded in the audit log under the impersonated user's ID with the session traceable back to the responsible admin.
This is the only mechanism by which one account's session can act as another's, and it exists specifically so that "an admin quietly used someone else's account" is structurally impossible to do without it being reconstructable after the fact.