FAQ

How is this different from a bastion or jump host?

A bastion is still a server your engineers log into with a key they hold. Tessera brokers the credential and the session: users never receive the target secret, access is granted per target and can be just-in-time and read-only, and everything is recorded. It is an access-control layer over your own infrastructure, not a network path — it does not carry general traffic, and it can only reach the targets you register.

Does Tessera carry any of my other network traffic?

No. It brokers four administrative protocols — SSH, the Kubernetes API, PostgreSQL/MySQL and RDP — and only to the targets you have registered. It does not route general internet traffic, does not give an engineer network reach beyond those targets, and has no path to any machine you do not own. Every connection is tied to a named user and written to the audit log; the product exists to attribute access, not to obscure it.

Do I need Vault or a separate control-plane cluster?

No. Tessera is one Go binary plus Postgres. Credentials are encrypted in the database; there’s no separate secrets engine or cluster to operate.

Do targets need an agent installed?

No. Brokering is agentless — targets just need a reachable endpoint (SSH, database, RDP, or the Kubernetes API).

What can Tessera broker?

SSH servers, Kubernetes clusters, PostgreSQL/MySQL databases, and Windows hosts over RDP. See the introduction for the full list.

What does the user actually run?

Their normal tools. ssh to a local port (or the built-in terminal) for servers, kubectl and other kubeconfig-based tools against a generated local kubeconfig, psql/mysql or a GUI client for databases, and a native remote-desktop window for RDP. Habits don’t change.

Can users see credentials?

For SSH, Kubernetes and databases: no. The secret is injected on the controller, inside the proxied connection, and is never sent to the client. The generated kubeconfig contains no real credential either — it points at a local tunnel.

RDP is the exception, and it is worth being precise about. The remote-desktop protocol authenticates before the session exists (NLA/CredSSP), so the credential has to reach the client that makes the connection. Tessera passes it to your local RDP client over stdin: it is never shown in the interface and never written to disk. But a user who holds a grant on an RDP target can obtain that password through the API, so treat an RDP grant as equivalent to giving that person the target’s password, with every issuance recorded in the audit log.

If that matters for a given host, do not grant standing RDP access to it — use just-in-time access so the grant, and the password with it, expires on its own.

Is the read-only filter a hard security boundary?

No — it’s a best-effort guardrail on mutating actions. For a real boundary, don’t grant the access (use just-in-time access) and rely on recording and audit. See Read-only sessions.

Which identity providers are supported?

Any OIDC provider — Keycloak, Okta, Azure AD, and others — plus SCIM 2.0 for provisioning and instant deprovisioning. See OIDC and SCIM.

What platforms does the desktop client run on?

Windows, macOS and Linux. There’s also a command-line client for headless use, WSL, servers and CI. The controller and web console are platform-independent.

Does re-importing my inventory create duplicates?

No. Targets are matched by kind and name and updated in place, so re-importing an edited file appends new targets and refreshes existing ones. See import & export.