Role-based access

Availability Pro · Ultimate · Enterprise.

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.

Export the access review

Access → Access review downloads a CSV of who can reach what, resolved.

That word is the point of it. The screen above shows grants, and a grant is not access: a single row reading “project Production, read-write” is forty servers or none, depending on what is in that project today. The export expands every grant against the targets it actually reaches and gives one row per person per target, with the mode, the scope that produced it, and the expiry if the access is temporary. It is the table an access review is done against, rather than the one it starts from.

The file carries a second table: every account holding authority over Tessera itself, with its management permissions. Who can hand access out is a stronger fact than who currently holds it, and a review that covers only the first half is half a review.

Two things worth knowing before it goes to an auditor:

• Access that has expired is not listed, because it is not access. The record that it once existed is in the audit log, which is the other half of the evidence and is exported from that screen.
• Downloading it is itself recorded, as access.review_exported. ISO/IEC 27001:2022 A.5.18 asks for access rights to be reviewed at planned intervals, and the thing an auditor tests is not the list but that the review happened and happened again; that entry is what shows it did.

Either Manage access or View audit can produce it, and neither can change anything through it.

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.