Appearance
Access Control
SeyalRun answers two different questions with two different mechanisms, and both must say yes:
- Role — what kind of thing may this person do? (view hosts, edit playbooks, manage users)
- Authorization — which specific hosts may they touch, with which credential, and for how long?
A role never implies access to a host. That separation is the point: a support engineer can have broad capability over the records without being able to open a session to anything they haven't been granted.
Roles
Exactly four built-in roles, in precedence order:
| Role | Capability |
|---|---|
superadmin | Everything, including the system segments (settings, log backend, housekeeping, command groups, login ACLs). |
admin | Broad administration — users (edit, not create), authorizations, access reviews, inventory, automation, zones. |
support | Day-to-day operations: inventory, automation, sessions. No zone topology, no system settings, no access reviews. |
user | Their own sessions and the hosts they've been authorized for. |
Users can hold more than one role; the highest applies for display and precedence.
superadmin and admin bypass the per-host authorization gate — that's the break-glass path, and it's deliberate. support and user are default-deny on resource actions (open a session, reveal a credential, run a job) and need an explicit grant even though support has broad CRUD over the underlying records.
Custom roles can be created with their own permission document.
Authorizations
An authorization is the grant that ties who to what:
| Field | |
|---|---|
| Subjects | One or more users and/or user groups |
| Targets | One or more hosts and/or host groups |
| Credential | Which vault credential the session uses |
| Actions | ssh, sftp, … |
| Window | Optional start date and expiry |
Approval lifecycle
New authorizations start as pending_approval — they grant nothing until approved. Eligible approvers are emailed a pair of single-use approve/reject links, and the decision is also available in the console.
The requester cannot approve their own request. This is enforced in both paths (the emailed link and the API), and the requester is excluded from the approver list to begin with — four-eyes on access grants, not an honour system.
Rejecting is likewise not a way to quietly withdraw a request that's under scrutiny.
Access reviews
Admin → Access Reviews creates a campaign that snapshots every currently active authorization. An admin walks each item and decides keep or revoke; a revoke feeds straight into the authorization's normal lifecycle (status="revoked", disabled) rather than a separate back door.
This is the "access is reviewed on a schedule, and here's the record" control (PCI DSS 7.2.4) — deliberately not a full GRC module.
Zones & gateways
A zone models a network segment reachable only through a jump host. Zones nest: the root ancestor's gateway connects first, and the zone's own gateway is the last hop before the target host — that chain becomes the SSH ProxyJump path. Cycles are rejected when you save the zone, because a cycle would make chain resolution loop forever at connect time.
Zone topology is admin-only. A support user can be authorized against hosts inside a zone without being able to reshape how traffic reaches them.
Multi-factor authentication
Two methods, per user: TOTP (authenticator app) and email code. MFA can be enforced for a user group, in which case members are forced through enrollment before they can use anything else.
MFA shows up in three places:
- Login — a session that hasn't verified yet is pinned to the MFA verify endpoint and can do nothing else.
- Credential reveal — showing a secret in the UI requires a fresh code, not just a logged-in session.
- Elevation — admins re-prove MFA to open a time-boxed elevated window (sudo-timeout style). The window lives in server-side session state and is never client-controlled; downstream services read it through one shared helper so the SSH-connect gate and the credential-reveal gate can't drift apart on what counts as "still elevated".
Login restrictions
| Control | What it does |
|---|---|
| Login ACLs | Allow/deny rules by user or group, source CIDR, time-of-day window and days-of-week, with priorities. |
| IP restrictions | Per-user (or group-enforced) CIDR allowlist, behind an explicit opt-in toggle. |
| Single session | Opt-in per user or group: a new login terminates the previous session instead of running two. |
| Forced password change | must_change_password pins the account to the change-password flow. |
Service accounts
A service account is a distinct object type, not a naming convention or a role: is_service_account / account_type are stored on the user and are what the code branches on. That makes "list every non-human account and review it on a schedule" a query rather than an audit of everyone's naming discipline.
Programmatic access
Tokens are the fourth gate, applying only to programmatic callers: a Personal Access Token is confined to its scopes on top of its owner's role and the authorization gate. See API Tokens & Scopes.
Related
- Security Model — sessions, vault, transport, secrets.
- Sessions & Supervision — command filtering and live oversight.
- Audit & Compliance — the record of what actually happened.