Role-based access

Requires the manage access permission. Access is granted, not distributed: a user can only see and reach a target if a grant says so.

Grant access

Under Access, create a grant by choosing:

a user,
a scope — all targets, all targets of one kind (all SSH, all databases, all RDP, or all clusters), a project, a group, or a single target,
a mode:
- view — can see the target exists, but not connect,
- read-only — can connect, but mutating actions are filtered (what’s blocked per kind),
- read-write — full access.

Standing grants are indefinite — they stay until you revoke or lower them. Only just-in-time access is time-boxed (see below).

Prefer the broadest scope that’s still correct — a read-only grant on a project covers every target in it, including ones you add later, so you grant once instead of per server.

Revoke and downgrade

Removing or lowering a grant takes effect immediately on live sessions, not just future ones:

Revoke access and the user’s active sessions to that scope are dropped.
Downgrade read-write to read-only and the filter applies to the running session without a reconnect.

This is the lever to reach for during an incident — tighten or cut access while a session is still open.

Approve just-in-time requests

If a user has no standing grant, they can request access. Requests appear under Requests with the target, requested mode, duration and reason. Approve or deny; on approval a time-boxed grant is created and auto-revoked when it expires. Approvals and denials are recorded in the audit log, and you can be notified when a request comes in.

Request durations are bounded: minimum 60 seconds, maximum 24 hours. A request for a specific target also requires that the requester already holds some grant that makes the target visible — you can’t request access to a target you can’t see.

Disable a user

Disabling a user (here or via SCIM) blocks their sign-in and kills their active sessions at once — the fastest way to cut someone off entirely.