Telepresence v2.31.1: Certificate Authentication Opens the Door for Every Cluster

| |

3 min read

Telepresence logo

Telepresence is the tool that lets you run your code on your laptop while pretending it is inside your Kubernetes cluster. You write code locally, Telepresence wires your local process into the cluster network, and your service can talk to (and be talked to by) everything else running in the cluster. No rebuild-deploy-wait cycle. No more works on my machine shrugs.

Think of it like a really convincing conference call. Your laptop dials in, the cluster thinks you are sitting right there at the table, and you can participate in every conversation as if you were deployed alongside your colleagues’ services. Except you have a real debugger, hot reload, and your own coffee machine.

Telepresence v2.31.1 solves a problem that has been quietly locking people out: if your Kubernetes cluster uses client certificates for authentication (which is extremely common on kubeadm, bare-metal, and kind clusters), Telepresence’s enforcing security mode would simply reject you. No token, no entry. That changes today.

What’s New in v2.31.1

x509 Client-Certificate Authentication

Here is the problem. Many Kubernetes clusters authenticate users via client certificates rather than bearer tokens. This is the default on kubeadm clusters, self-managed bare-metal setups, and local kind development clusters. When Telepresence ran with security.authentication.mode: enforcing, it needed a bearer token to verify your identity. A client certificate does not produce one. So the traffic-manager looked at your credentials, found no token, and showed you the door.

v2.31.1 introduces a dedicated auth-only TLS listener in the traffic-manager. When a certificate-based client connects, the manager performs a one-shot TLS handshake, verifies the client certificate against the cluster’s client CA, and hands back a short-lived bearer token for the regular gRPC channel. You get an authenticated identity, and everything that depends on it — session binding, SubjectAccessReview-based intercept authorization — starts working.

# Active by default when authentication is enforced
security:
  authentication:
    mode: enforcing
    x509:
      enabled: true  # opt out with false

The feature is on by default under enforcing mode. The Helm chart also creates a RoleBinding in kube-system to the stock extension-apiserver-authentication-reader Role so the manager can read the client CA. See PR #4223 for the full implementation.

Port-Forward Stream Corruption Fix

This one is for anyone who has ever watched their Telepresence session mysteriously hang for no apparent reason. The root cause was hiding inside the port-forward connection layer.

Two defects in portConn were conspiring to bring down every stream pair sharing a port-forward connection. First, deadline calls were being forwarded to the SPDY stream layer, which has no concept of per-stream deadlines. The deadline landed on the shared network connection instead, poisoning all sibling pairs. One stream sets a deadline, every other stream dies. Second, portConn.Close left local pending reads permanently blocked, violating the net.Conn contract.

Both are now fixed. portConn swallows deadlines on both WebSocket-tunneled and direct SPDY transports, and Close now resets streams after the FIN to properly unblock local readers. See PR #4224.

Dependency Security Update

The dependency refresh in PR #4220 is worth noting because it pulls in gRPC 1.82.1, which patches an HTTP/2 server frame-flood denial-of-service vulnerability. The fix makes the server stop reading a connection when flooded by non-DATA/HEADERS frames, capped at 100 by default. The golang.org/x/net, x/crypto, and x/sys packages were also bumped to their latest versions.

Should You Upgrade?

If you run Telepresence on a cluster that uses client certificates for authentication, the answer is yes, today. You have been locked out of enforcing mode, and this release hands you the key. Everyone else gets a solid reliability fix and a security-relevant dependency bump — not flashy, but the kind of thing you want in your tooling before it bites you.

One stream sets a deadline, every other stream dies. That is the kind of bug that makes you question reality for about three hours before you find it.

Learn More