Key concepts

Tessera’s model in one sentence: access is granted, not distributed. There are no shared keys or passwords to hand out — the controller holds the credentials, and a grant decides who can use them, where, and how.

Targets & credential injection

A target is anything users connect to through Tessera: a kind (ssh, kubernetes, database, rdp), connection details, and a stored credential. Credentials are encrypted at rest with AES-256-GCM and are write-only in the console — once saved, a secret is never shown again, only replaced. When a user connects, the controller decrypts the credential in memory and presents it to the target on the user’s behalf. For SSH, databases and Kubernetes the injection happens on the controller and the secret never reaches the user’s machine. RDP is the exception: the credential is delivered to the desktop app and injected into the bundled remote-desktop client in the app’s memory — never written to disk, shown in the UI, or saved to the OS credential store, but it does reach the desktop process. For SSH targets and bastions the host key is pinned on first connection (TOFU) and a later change refuses the connection.

Set them up: Targets · Credentials & SSH keys

Grants & RBAC

A grant ties a user to a scope (all targets, all targets of one kind — all SSH, all databases, all RDP, or all clusters — a project, a group, or one target) at a mode: view (see it exists), read-only (connect, mutations filtered), or read-write (full access). No grant means the user can’t even see that the target exists. Management rights (manage targets / manage access / manage users / administrator) are separate flags, independent of connect access. Enforcement is live: revoking access drops active sessions, downgrading applies the read-only filter to a running session without a reconnect.

Set it up: Role-based access

Just-in-time access

Instead of standing access, users can hold nothing by default and request access when they need it: they pick a mode, a duration and a reason; an approver with manage access approves; a time-boxed grant is created; when it expires, a background sweeper revokes it and drops any live session. Request durations are bounded — at least 60 seconds and at most 24 hours. Every request, decision and approver lands in the audit log.

Use it: Request access · approve it: Role-based access

Read-only sessions

A read-only grant filters mutating actions on the controller, where the user can’t turn it off: blocked shell commands plus the whole SFTP subsystem and scp (file transfer blocked in both directions) on SSH, write statements on databases, mutating API verbs on Kubernetes. For RDP a read-only grant is accepted but behaves as read-write — the Windows desktop isn’t filtered, so rely on session recording and audit. The filter is a guardrail against accidental change, not a hard security boundary; for sensitive targets prefer JIT and recording as the primary controls.

On SSH specifically, a shell is expressive enough to evade any command blocklist. Where you need a guarantee rather than a guardrail, give Tessera a read-only OS account on the target and let the account be the boundary — see Hard read-only on SSH.

Configure it: Read-only policies

Sessions & recording

Every connection passes through the broker, so every session is observable: SSH commands, database queries and Kubernetes requests are logged per-command / per-request in all editions. Optionally (Pro and up), the full terminal stream of an SSH session is recorded in asciinema format for replay in the console. Administrators see active sessions live and can force-close any of them; the audit stream can be exported to a SIEM as JSON.

Review it: Audit log