Does this replace Kubernetes RBAC?

No, and it should not. Kubernetes RBAC decides what a credential may do inside the cluster. Tessera decides who may use that credential, for how long, and leaves a record of it. They answer different halves of the same question, and the cluster's own rules still apply underneath.

Do engineers have to change how they work?

No. The client writes a local kubeconfig that carries no real credential and points at a local endpoint, so kubectl behaves exactly as it did. exec , logs -f and port-forward are bridged and work normally.

Is anything installed in the cluster?

No. Tessera is agentless: it speaks to the API server as a client would, so there is no operator, no sidecar and no admission webhook to install, upgrade or debug.

What does a read-only session actually block?

Mutating API calls are rejected before they reach the API server, and exec , attach and port-forward are blocked because they are interactive write channels. logs -f keeps working, which is usually the whole point of read-only access during an incident.

Which edition is this in?

Brokering is in every edition including Community. Read-only sessions are Pro and above: on Community every user connects read-write. Editing which resources read-only blocks is Ultimate. The editions table has the rest.

Kubernetes

Kubernetes access control, without handing out kubeconfigs

A kubeconfig is a credential in a text file, and text files get copied. Tessera keeps the cluster credential on the broker, hands the engineer a local config with nothing sensitive in it, and writes down what happened.

The problem is the kubeconfig, not the cluster

Kubernetes RBAC is good. What is usually weak is everything that happens before it: a kubeconfig gets generated, pasted into a chat, copied to a laptop, committed to a dotfiles repo, and inherited by whoever joins the team next. The cluster enforces its rules perfectly against a credential that five people share and nobody can revoke individually.

The second gap is the record. The API server's own audit log tells you a service account did something. It rarely tells you which human was holding that service account at the time, and that is the question an access review asks.

What brokering changes

The credential is injected per request

Because kubectl carries authentication on every request, Tessera brokers Kubernetes as an HTTP reverse proxy rather than a byte tunnel. The engineer's local kubeconfig points at a local endpoint and holds no real credential; the controller attaches the cluster's bearer token or client certificate to each request as it passes. There is nothing on the laptop worth stealing.

As defence in depth the controller strips any Impersonate- headers the client sends, so a user cannot ask the API server to treat them as somebody else.

Read-only is enforced, not requested (Pro and above)

A read-only session rejects mutating API calls before they reach the API server, and blocks exec, attach and port-forward, which are write channels wearing a read-shaped name. logs -f still works, so somebody can watch an incident without being able to touch it. An administrator can downgrade a live session from read-write to read-only without the other person reconnecting.

Worth knowing before you test it: read-only sessions start at Pro. On Community every user connects read-write, and a read-only request is granted as read-write rather than refused.

Nothing runs in the cluster

No operator, no sidecar, no admission webhook, nothing to upgrade in lockstep with the cluster and nothing that breaks a release. Adding a cluster is importing a kubeconfig once; after that, the cluster does not know Tessera exists.

What it does not do

It does not replace Kubernetes RBAC, and you should be suspicious of anything that claims to. The cluster's own rules still decide what a credential can do. Tessera decides who gets to use it and for how long, and it is the only one of the two that can answer a question about last March. Both halves are load-bearing.

Where this fits with the rest

The same broker covers SSH, databases and Windows over RDP, with the same grants, the same approvals and one audit log across all of them. If the reason you are reading this is an upcoming audit, the shorter route is what an auditor asks for. If it is a jump host you inherited, that is the bastion page.

Questions people ask before they try it

Does this replace Kubernetes RBAC?: No, and it should not. Kubernetes RBAC decides what a credential may do inside the cluster. Tessera decides who may use that credential, for how long, and leaves a record of it. They answer different halves of the same question, and the cluster's own rules still apply underneath.
Do engineers have to change how they work?: No. The client writes a local kubeconfig that carries no real credential and points at a local endpoint, so kubectl behaves exactly as it did. exec, logs -f and port-forward are bridged and work normally.
Is anything installed in the cluster?: No. Tessera is agentless: it speaks to the API server as a client would, so there is no operator, no sidecar and no admission webhook to install, upgrade or debug.
What does a read-only session actually block?: Mutating API calls are rejected before they reach the API server, and exec, attach and port-forward are blocked because they are interactive write channels. logs -f keeps working, which is usually the whole point of read-only access during an incident.
Which edition is this in?: Brokering is in every edition including Community. Read-only sessions are Pro and above: on Community every user connects read-write. Editing which resources read-only blocks is Ultimate. The editions table has the rest.

Start free How clusters are added