Skip to content
Tessera Tessera Docs

Kubernetes clusters

Availability All editions. Configurable read-only policy: Ultimate.

Requires the manage targets permission.

Import a kubeconfig

Section titled “Import a kubeconfig”
  1. Go to Kubernetes → Import kubeconfig.
  2. Paste a kubeconfig (or drag the file in). Tessera reads the current context and extracts:
    • the API server endpoint and CA,
    • the user credential — a bearer token or a client certificate (auto-detected).
  3. A Kubernetes target is created and the credential is encrypted at rest. The cluster appears on the Kubernetes tab, separate from Servers.

You can also add clusters in bulk with import, where a kubernetes target carries the kubeconfig inline.

How brokering works

Section titled “How brokering works”

kubectl carries auth in every request, so Tessera brokers Kubernetes with an HTTP reverse-proxy rather than a byte tunnel. The client writes a local kubeconfig with no real credential, pointing at a local endpoint; the controller injects the cluster’s token or client certificate per request, and strips any client Impersonate-* headers as defense-in-depth. exec, logs -f and port-forward (SPDY / WebSocket upgrades) are bridged, so they work as usual in read-write sessions. In a read-only session exec, attach and port-forward are blocked (interactive write channels), while logs -f still works.

How users connect

Section titled “How users connect”

From the desktop app or CLI, connecting to the cluster generates a kubeconfig at a stable path:

Terminal window
export KUBECONFIG=~/.tessera/kubeconfigs/<cluster>.yaml
kubectl get pods -A

The path and port are stable per account and cluster, so any kubeconfig-based tool keeps working across reconnects.

Read-only clusters

Section titled “Read-only clusters”

A read-only grant filters all mutating requests (any non-read HTTP method — create, update, patch, delete), plus exec/attach/port-forward and the pod/service/node proxy subresource, at the proxy, and is enforced live. Those mutation and interactive-channel blocks are an always-on floor that can’t be turned off. On Ultimate you can additionally configure the blocked subresources and read-blocked resources — you can only add to the floor, not remove from it — see Read-only policies.

Audit

Section titled “Audit”

Each request is logged with verb, resource, namespace, name and status — see the audit log.

Cookies