Proto commits in telepresenceio/telepresence

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2026-08-13

Resolve symbolic service ports through the traffic-manager A symbolic service port (--forward echo:http) was resolved by the root daemon with a direct Kubernetes services get, which an external-endpoint client cannot make and a minimal-RBAC client is refused. The manager now serves a ResolveServicePort RPC, on both the in-cluster and external listeners, that returns the service's ClusterIP and numeric port. The user daemon owns port resolution: a symbolic port goes to the manager, falling back to the direct Kubernetes lookup only when the manager answers Unimplemented (and to a use-a-numeric-port error in external mode); a numeric port with a hostname resolves through the root daemon's existing LookupIP. The root daemon's ResolvePort RPC is removed along with its implementation, and servicePortByName moves to k8sapi.ServicePortByName so the manager and the fallback share it. Signed-off-by: Thomas Hallgren <thomas@tada.se>

The documentation is generated from this commit.

Resolve ambiguous workload names by priority order again The workload-kind field on EnsureAgentRequest, the --workload-kind ingest flag, and the manager's ambiguity rejection existed to feed the kind-qualified attachment review, which needed the kind before it could authorize. With that review gone, targeting is the only thing the kind selected, and the pre-existing priority-order resolution serves it as it always has. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Serve namespaces and pod logs to clients through the traffic-manager A client watching all namespaces now receives the manager's managed- namespace set over the new WatchNamespaces RPC, and telepresence gather-logs streams traffic-manager and traffic-agent logs (and pod manifests) over the new StreamLogs RPC, the manager reading them on the client's behalf. Both are gated on manager >= 2.32.0 and fall back to the client's direct Kubernetes API access against older managers, so a client needs no permission to list pods, read pods/log, or list namespaces. Log access is authorized by get on the logs and logs/yaml telepresence.io resources, independent of the authorization gate, and the chart's client Roles grant them. StreamLogs refuses an unauthenticated caller in every authentication mode, and its chunk size, per-pod byte limit, pod concurrency, per-session stream count, and deadline are tunable through the chart's new logStreaming values. WatchWorkloads applies a per-session authorized-namespace probe to an explicitly named namespace, and the long-dead GetLogs stub is removed from the manager's RPC surface. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add an authorization gate and centralize manager-side reviews The traffic-manager authorizes callers against a configurable grant: the legacy pods/portforward permission, Telepresence's own policy attributes (create on connections.telepresence.io to connect, create or get on kind-qualified attachments/<kind> to intercept or ingest), or either -- security.authorization.gate: portforward, telepresence, or any, defaulting to any. Reviews run before the first side effect (ArriveAsClient, PrepareIntercept, EnsureAgent, CreateIntercept), a caller that authorizes only via the legacy grant is warned about in the manager log, and the chart renders client Roles to match while keeping the connect role's transport rules for every gate. A reconnect into a fresh manager re-runs the connect review and reviews every restored intercept. Restored state is rebuilt from the client's specs alone -- reconstructed id, session-owned ClientSession, WAITING disposition -- with child intercepts regenerated from the parent's pod ports. A denied intercept is omitted from the restore; an unavailable review fails the reconnect so the client retries. EnsureAgent resolves the workload kind before authorization so the kind reviewed is the kind mutated, and rejects an ambiguous same-name workload unless the caller states the kind (EnsureAgentRequest.workload_kind, telepresence ingest --workload-kind). Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-08-09

Resolve symbolic service ports through the traffic-manager A symbolic service port (--forward echo:http) was resolved by the root daemon with a direct Kubernetes services get, which an external-endpoint client cannot make and a minimal-RBAC client is refused. The manager now serves a ResolveServicePort RPC, on both the in-cluster and external listeners, that returns the service's ClusterIP and numeric port. The user daemon owns port resolution: a symbolic port goes to the manager, falling back to the direct Kubernetes lookup only when the manager answers Unimplemented (and to a use-a-numeric-port error in external mode); a numeric port with a hostname resolves through the root daemon's existing LookupIP. The root daemon's ResolvePort RPC is removed along with its implementation, and servicePortByName moves to k8sapi.ServicePortByName so the manager and the fallback share it. Signed-off-by: Thomas Hallgren <thomas@tada.se>

The documentation is generated from this commit.

Resolve ambiguous workload names by priority order again The workload-kind field on EnsureAgentRequest, the --workload-kind ingest flag, and the manager's ambiguity rejection existed to feed the kind-qualified attachment review, which needed the kind before it could authorize. With that review gone, targeting is the only thing the kind selected, and the pre-existing priority-order resolution serves it as it always has. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-08-08

Serve namespaces and pod logs to clients through the traffic-manager A client watching all namespaces now receives the manager's managed- namespace set over the new WatchNamespaces RPC, and telepresence gather-logs streams traffic-manager and traffic-agent logs (and pod manifests) over the new StreamLogs RPC, the manager reading them on the client's behalf. Both are gated on manager >= 2.32.0 and fall back to the client's direct Kubernetes API access against older managers, so a client needs no permission to list pods, read pods/log, or list namespaces. Log access is authorized by get on the logs and logs/yaml telepresence.io resources, independent of the authorization gate, and the chart's client Roles grant them. StreamLogs refuses an unauthenticated caller in every authentication mode, and its chunk size, per-pod byte limit, pod concurrency, per-session stream count, and deadline are tunable through the chart's new logStreaming values. WatchWorkloads applies a per-session authorized-namespace probe to an explicitly named namespace, and the long-dead GetLogs stub is removed from the manager's RPC surface. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add an authorization gate and centralize manager-side reviews The traffic-manager authorizes callers against a configurable grant: the legacy pods/portforward permission, Telepresence's own policy attributes (create on connections.telepresence.io to connect, create or get on kind-qualified attachments/<kind> to intercept or ingest), or either -- security.authorization.gate: portforward, telepresence, or any, defaulting to any. Reviews run before the first side effect (ArriveAsClient, PrepareIntercept, EnsureAgent, CreateIntercept), a caller that authorizes only via the legacy grant is warned about in the manager log, and the chart renders client Roles to match while keeping the connect role's transport rules for every gate. A reconnect into a fresh manager re-runs the connect review and reviews every restored intercept. Restored state is rebuilt from the client's specs alone -- reconstructed id, session-owned ClientSession, WAITING disposition -- with child intercepts regenerated from the parent's pod ports. A denied intercept is omitted from the restore; an unavailable review fails the reconnect so the client retries. EnsureAgent resolves the workload kind before authorization so the kind reviewed is the kind mutated, and rejects an ambiguous same-name workload unless the caller states the kind (EnsureAgentRequest.workload_kind, telepresence ingest --workload-kind). Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-08-02

Document the traffic-agent port authentication A new "Traffic-agent ports" section in the authentication reference covers the session credential's two forms, the mode-mirrored enforcement, the per-port mechanisms (FTP password token, gRPC metadata with the dial-watcher displacement rule, SFTP confinement plus the enforcing-mode tunnel-source gate and why SFTP is not TLS-wrapped), the accepted residual weaknesses, and the version-skew story. Code comments that referenced the working design note now point at this section. Signed-off-by: Thomas Hallgren <thomas@tada.se> (cherry picked from commit 9c53dc3cc5735a0831f3a5fa8b3a7194ef264a4c)

Mint a session-scoped credential for traffic-agent authentication The traffic-manager now creates its QUIC CA unconditionally, so a signing key exists even when the QUIC tunnel listener is disabled; the endpoint advertisement stays gated on TUNNEL_QUIC_PORT as before. A new GetSessionCredential RPC returns, to the owning session only, a credential in two forms rooted in that CA: the existing session client certificate (CN = session ID) for TLS transports, and a compact signed bearer token (pkg/sessiontoken, ECDSA over a domain-separated digest, offline-verifiable against the CA certificate) for places a certificate cannot ride -- the FTP password and gRPC metadata. Both halves share one 24h expiry, and a manager restart still revokes everything. GetQuicAgentCert additionally reports the manager's authentication mode, so agents can mirror it when deciding whether to require the credential. Signed-off-by: Thomas Hallgren <thomas@tada.se> (cherry picked from commit accf709c34c09e76ac7fca425df40e30c8368592)

Require an owned client session to set the manager log level SetLogLevel accepted any caller: no session, no principal, no authorization, yet the new level propagated to the manager and to every agent via WatchLogLevel. LogLevelRequest now carries the client's SessionInfo (a new, optional field, so the wire format stays compatible), the client populates it, and the manager resolves it with ensureClientSession, rejecting a session owned by another identity. A request without a session -- an older client -- is still honored unless security.authentication.mode=enforcing, where it is rejected as Unauthenticated. Signed-off-by: Thomas Hallgren <thomas@tada.se> (cherry picked from commit 8111d6ec970263d758c13ddbed966c65c3d1b5c3)

2026-07-28

Add x509 client-certificate authentication of clients A kubeconfig whose credentials are a client certificate yields no bearer token, so the traffic-manager could not identify such callers: they ran unidentified in permissive mode and were rejected in enforcing mode. The manager now runs an auth-only TLS listener whenever the authentication mode is enforcing, reachable through the same pods/portforward grant the client already holds. A client whose kubeconfig cannot produce a bearer token performs a one-shot TLS handshake against it, presenting the kubeconfig's client certificate. The manager verifies the certificate chain against the cluster client CA published in the extension-apiserver-authentication ConfigMap, maps CN/O to username/groups exactly as the API server would, and returns a short-lived opaque bearer token that the client then presents as ordinary per-RPC authorization metadata on the unchanged h2c channel. The listener is active by default under enforcing mode, so flipping on enforcement authenticates cert-only clients instead of locking them out; the Helm value security.authentication.x509.enabled=false opts out, and has no effect under any other mode. When active, the chart binds the manager's ServiceAccount to the stock extension-apiserver-authentication-reader Role in kube-system so the manager can read the client CA. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-07-26

Add x509 client-certificate authentication of clients A kubeconfig whose credentials are a client certificate yields no bearer token, so the traffic-manager could not identify such callers: they ran unidentified in permissive mode and were rejected in enforcing mode. The manager now runs an auth-only TLS listener whenever the authentication mode is enforcing, reachable through the same pods/portforward grant the client already holds. A client whose kubeconfig cannot produce a bearer token performs a one-shot TLS handshake against it, presenting the kubeconfig's client certificate. The manager verifies the certificate chain against the cluster client CA published in the extension-apiserver-authentication ConfigMap, maps CN/O to username/groups exactly as the API server would, and returns a short-lived opaque bearer token that the client then presents as ordinary per-RPC authorization metadata on the unchanged h2c channel. The listener is active by default under enforcing mode, so flipping on enforcement authenticates cert-only clients instead of locking them out; the Helm value security.authentication.x509.enabled=false opts out, and has no effect under any other mode. When active, the chart binds the manager's ServiceAccount to the stock extension-apiserver-authentication-reader Role in kube-system so the manager can read the client CA. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add x509 client-certificate authentication of clients A kubeconfig whose credentials are a client certificate yields no bearer token, so the traffic-manager could not identify such callers: they ran unidentified in permissive mode and were rejected in enforcing mode. The manager now runs an auth-only TLS listener whenever the authentication mode is enforcing, reachable through the same pods/portforward grant the client already holds. A client whose kubeconfig cannot produce a bearer token performs a one-shot TLS handshake against it, presenting the kubeconfig's client certificate. The manager verifies the certificate chain against the cluster client CA published in the extension-apiserver-authentication ConfigMap, maps CN/O to username/groups exactly as the API server would, and returns a short-lived opaque bearer token that the client then presents as ordinary per-RPC authorization metadata on the unchanged h2c channel. The listener is active by default under enforcing mode, so flipping on enforcement authenticates cert-only clients instead of locking them out; the Helm value security.authentication.x509.enabled=false opts out, and has no effect under any other mode. When active, the chart binds the manager's ServiceAccount to the stock extension-apiserver-authentication-reader Role in kube-system so the manager can read the client CA. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-07-22

Add an authentication mode with opt-in enforcement A new Helm value security.authentication.mode governs how the traffic-manager treats caller authentication: - disabled: no token validation at all. - permissive (the default): tokens are validated and authorization decisions logged, but no call is rejected. Sessions bound to an authenticated identity are still protected from other identities. - enforcing: calls without a valid bearer token are rejected with Unauthenticated (the read-only Version handshake and health checks remain open), intercept creation requires the pods/portforward RBAC check to pass, and an agent whose bound-token pod claims do not match its presented identity is rejected. TokenReview infrastructure failures under enforcement yield Unavailable, never PermissionDenied, so an API-server outage is distinguishable from a denial. The Version response now carries auth_supported and auth_required so a client learns the manager's mode up front: a kubeconfig that cannot produce a bearer token (client-certificate credentials) gets a clear error when the manager enforces authentication, instead of a string of rejected RPCs. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-07-19

Add telepresence apply and delete driven by a workstation state manifest The new "telepresence apply -f <manifest>" command brings the workstation to the state described by a YAML manifest: an optional connection with its connect flags, and an ordered set of attachments (intercept, replace, ingest, or wiretap) complete with theirs. The manifest is validated against the embedded JSON schema before anything happens. Apply is idempotent. A declared connection goes through the ordinary connect flow, so the user daemon performs its authoritative alignment check (UpdateStatus -> CheckStatus) when a session already exists and connects with the manifest's flags when it doesn't. The --dry-run flag reports what apply would do without changing anything; it uses the new read-only CheckConnect connector RPC to get the same full-fidelity alignment check without mutating daemon state, and never launches a daemon or connects. Attachments are established in manifest order: missing ones are created detached, matching ones are left untouched, and ones whose manifest- specified fields differ from the daemon's view are re-created. "telepresence delete -f <manifest>" tears the state down again: the attachments are removed in reverse manifest order (an absent attachment is reported but not an error), and the connection is disconnected only when the manifest declares it. A manifest without a connection operates on, and never tears down, the currently selected connection. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-07-18

Add proto contracts for the combined session-events watcher A new manager RPC, WatchSessionEvents, multiplexes the client-scoped agent-pod projection and the client's own intercepts onto a single stream: SessionEventsDelta carries AgentPodInfoDelta, scoped to a requested namespace set plus the connected namespace, and InterceptInfoDelta. AgentPodInfo gains the agent's version so the stream covers everything the client reads from it, always fully populated. Bulk container data (environments, mounts, ports) is deliberately not streamed; clients retrieve it on demand from the EnsureAgent response or from InterceptInfo. A new daemon RPC, WatchAgentPods, lets the user daemon push the relayed agent-pod deltas to the root daemon, governed by the new NetworkConfig.agent_pod_namespaces field. Additions only; no existing RPC, message, or field changes. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-07-17

Promote QUIC architecture to a permanent reference doc The design plan under docs/plans/quic-transport/ had become the de-facto architecture reference for the whole QUIC subsystem: 32 code, proto, and chart comments cited its design.md by section name. That file is deleted when the plan directory is cleaned up at the end of the feature, which would have left those citations dangling or forced their rationale to be stripped. Move the durable architecture half of design.md into a permanent docs/reference/quic-transport-architecture.md (present tense, describing the shipped system), keeping the section names the comments cite intact ('The forwarder', 'Agent connections over QUIC', 'Trust bootstrap', 'Zero-configuration endpoint discovery', 'Where it plugs in'). Repoint every citation there and regenerate manager.pb.go for the proto comment change. The planning/measurement half of design.md (the improvement sub-plans, now all resolved, and the measurement methodology, which lives operationally in perf/README.md) is not carried over here; it is harvested into the PR description and then design.md is deleted with the rest of the plan directory in the final phase-8 commit. No functional code change; build, go vet, gofumpt, golangci-lint (lll 180), protolint, and helm lint all clean. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add QuicTunnelEndpoint.candidates for zero-config discovery (phase 7) Additive wire change ahead of the manager-side discovery work: a QuicEndpointCandidate list, ordered by the manager's preference, alongside the existing host/port fields. host/port keep carrying the first candidate so an intermediate build of the client (this field added, discovery not yet wired up) still works; a client built before this field existed simply never reads it and falls back to host/port, satisfying the plan's older-manager/older-client compatibility requirement in both directions. make protoc regenerated the Go bindings; make lint-rpc (protolint) is clean. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Route traffic-agent connections over QUIC through the forwarder Extend the forwarder architecture to the client<->agent data path (phase 6 of docs/plans/quic-transport/design.md). Traffic agents -- sidecar and node-agent alike -- now run a QUIC listener on their pod IP, reachable only through the forwarder, and the client dials them over QUIC instead of a per-pod Kubernetes port-forward. The agent fetches a server certificate for its SNI name over its existing authenticated manager session (GetQuicAgentCert), re-fetching on manager reconnect since a manager restart mints a new ephemeral CA, and swaps the listener's TLS material without a restart. Accepted QUIC streams are handed to the agent's existing gRPC server, so every agent RPC works over QUIC with no change to the services themselves. The client's agentpf dials the forwarder with the agent's SNI when the manager advertises one (AgentPodInfo.quic_sni), one QUIC connection per agent, and falls back per-agent to the port-forward on any failure. The forwarder learns each agent's pod IP and port from the extended allowlist and routes agent SNIs to them; its manager connection now uses keepalives so a replaced manager pod is noticed within seconds and the allowlist refreshed. telepresence status reports the transport of each connected agent, and the integration suite gains coverage that attachments actually ride QUIC and that cluster-originated traffic to an intercepted workload survives a full traffic-manager outage. Also updates the mirrord and Gefyra comparisons to describe the opt-in QUIC data path. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Route all QUIC tunnel traffic through a stateless packet forwarder Introduce the quic-forwarder: a stateless QUIC packet router, shipped as a new subcommand in the tel2 image, that owns the single exposed UDP entry point for the QUIC tunnel transport. A connection's first packet is routed by the SNI in its ClientHello (readable without terminating TLS, reassembled across Initial packets when a post-quantum-sized ClientHello splits); every later packet is routed by the server-issued connection ID, which backends mint to encode their own pod IP. TLS remains end-to-end between client and backend; the forwarder holds no keys and no durable state, so restarts and replicas are cheap and established connections survive a forwarder pod replacement via QUIC path validation. Every routing decision is validated against an allowlist of live backend pod IPs, streamed from the traffic-manager over the new WatchQuicBackends RPC; anything that resolves to no backend -- non-QUIC junk, unknown QUIC versions, SNI-less or foreign ClientHellos, forged connection IDs -- is dropped silently. The traffic-manager's QUIC listener moves behind the forwarder: it now listens pod-internally with a connection-ID generator encoding its pod IP, and the traffic-manager-quic Service fronts the forwarder Deployment instead of the manager. Clients are unaffected; the endpoint descriptor now simply advertises the forwarder's address. The new pkg/quicfwd package carries the wire-format logic (CID codec, RFC 9001 Initial unprotection and SNI extraction, packet classification), validated against the RFC's test vectors and against Initials captured from the quic-go version in go.mod. The QuicTunnel integration suite now runs entirely through the forwarder and gains Test_ForwarderRestartSurvival, which deletes the forwarder pod mid-session and requires the transport to remain quic through recovery. This is phase 5 of docs/plans/quic-transport/design.md. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add opt-in QUIC transport for the tunnel The traffic-manager can now expose a QUIC endpoint (Helm value quicTunnel.enabled) that clients automatically upgrade manager-bound tunnel streams to when it is reachable. QUIC's independent streams remove the head-of-line blocking that the shared port-forwarded HTTP/2 connection imposes across flows, and the connection survives client network changes. The port-forwarded gRPC transport remains the default and the fallback whenever the endpoint is disabled or unreachable. Trust is bootstrapped over the RBAC-authenticated port-forwarded connection: the manager generates an ephemeral CA at startup and mints session-scoped client certificates (CN = session ID) that the mTLS QUIC listener verifies against each stream's declared session, so a kubeconfig remains the only client credential. The transport plugs in behind the tunnel.Provider seam with identical TunnelMessage framing (4-byte length prefix), reusing the stream state machine and the manager-side state.Tunnel handling unchanged. The client dials opportunistically after session establishment with a 3s budget, keeps idle connections alive with 15s pings, and permanently falls back to gRPC on the first mid-session failure; caller-canceled streams do not trip the fallback. Agent tunnels stay on port-forward. telepresence status reports the active transport, the root daemon emits a session.transport usage report when the transport resolves, and the QuicTunnel/QuicTunnelDisabled integration suites exercise the Helm chart with VPN-only traffic, sidecar and node-agent attachments, and the manager relay in VPN-only mode. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-07-11

Rename engagement to attachment in code, add the detach command The new "telepresence detach" command replaces "telepresence leave", which remains functional as a hidden, deprecated alias. Identifiers and user-facing strings follow the new attachment vocabulary (AttachmentType, "ready to attach", compose progress messages, MCP tool names). The generated CLI pages, README nav, and Helm values schema are regenerated accordingly. Wire-level compatibility is preserved: no proto RPC, message, or field names change (one comment only), and the manager still reads the lastEngagementTime key from agent-state configmaps written by older managers. Integration tests gain Cluster.AttachVerb(), a three-way version gate for the list-output wording (intercept up to 2.21, engage from 2.22, attach from 2.30), replacing the previous two-way checks. A CHANGELOG entry documents the rename under the unreleased 2.30.0, and the node-agent note in that same block is reworded to the new vocabulary. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add node-agent fields to the EnsureAgent and ingest wire contracts Extend EnsureAgentRequest with a node_agent bool, mirroring InterceptSpec, so a caller can request that the manager serve the agent via a node-hosted Job instead of injecting a sidecar. Add a new ReleaseAgent rpc and ReleaseAgentRequest message so a caller can drop its claim on a node-agent once it is done, letting the manager reap the Job when nothing else needs it. Extend connector's IngestRequest with a matching node_agent bool for the client-side ingest flag that will follow in a later change. The manager service embeds UnsafeManagerServer, so the ManagerServer interface assertion requires every rpc to be implemented; add ReleaseAgent to service.go with the usual session/namespace preamble, and a State.ReleaseAgent stub whose lease bookkeeping lands next. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Dial node-agents via the traffic-manager's namespace A client reaches a traffic-agent through a Kubernetes port-forward addressed by pod name and namespace, both taken from the agent's registration. A node-agent registers under the intercepted workload's namespace, but its Job pod runs in the traffic-manager's namespace, so the port-forward targeted a pod that does not exist and every dial to the agent's gRPC server timed out, leaving node-agent intercepts stuck until the intercept timeout expired. AgentInfo and AgentPodInfo gain an additive node_agent flag: the agent reports it (the node-agent Config knows what it is, so no new env is needed), the manager copies it into the agent-pod watch, and the client selects the traffic-manager's namespace for the port-forward when the flag is set. Sidecar agents leave the flag unset and are dialed exactly as before, so older agents and managers interoperate unchanged. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add node-agent request selector and manager feature gate Introduces the API by which a client selects node-agent mode -- a node-hosted traffic-agent served by a manager-created Job rather than an injected sidecar -- plus the manager-side gate that governs it. A new optional node_agent field on InterceptSpec carries the request (wire-compatible: a fresh field number, defaulting to false, so existing clients and managers are unaffected). A NodeAgentEnabled manager environment flag gates the feature. PrepareIntercept branches on the request: it is rejected with a user error when the manager has node-agent mode disabled, and otherwise routed to an ensureNodeAgent seam. The Job construction and lifecycle behind that seam are added in a later change; for now it reports that the mode is not yet available. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-06-16

Show ingress URLs for intercepted service ports The output of "telepresence intercept" and "telepresence list" now shows the ingress URLs through which an intercepted service port can be reached. When the intercept uses HTTP header filters, a ready-to-paste curl example with the matching -H flags is included. The URLs are derived from the RouteAssociations that the traffic-manager attaches to each ServiceAssociation. A RouteAssociation now also carries the load-balancer addresses of its route object, used to build a URL when the route declares no hosts. To guarantee that the workload snapshot contains the route data when the intercept command displays its result, the userd starts the workload info watcher as soon as an intercept is requested, and waits for the workload update that reflects the established intercept before CreateIntercept returns. Two bugs surfaced during testing of this feature: - PrepareIntercept never propagated the resolved service name, so the intercept spec lacked it unless the user passed --service. The resolved name is now copied into both the PreparedIntercept and the InterceptSpec. - Removing an intercept deleted the workload's agent config from the traffic-manager's cache, because restoreAppContainer returned a nil config to signal "no change" and Map.Update interprets nil as removal. This also caused a needless config regeneration on each subsequent engagement of the same workload. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Derive workload exposure from the agent's Sidecar config Workload services and routes are only of interest for workloads that are known to have a traffic-agent, and such workloads always have a Sidecar config that already contains the service associations. Use that config as the source instead of re-running service discovery, and skip ingress discovery entirely for workloads without an agent. Restructure the RPC so that each RouteAssociation is nested under the ServiceAssociation it targets, removing the four-field join key and the namespace fields that could never differ from the namespace of the WorkloadInfo. Register an ingress informer when the namespace informer factories are started. Without it, the ingress lister cache never synced, so every lookup silently fell through to a direct API call. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Expose workload services and routes

2026-06-14

Route dual-stack clusters correctly with telepresence connect --docker In --docker mode the teleroute network gave every cluster route a single next-hop, chosen by whether any route was IPv6. On a dual-stack cluster the IPv4 routes then received an IPv6 next-hop (or the reverse) and became unusable. The JoinResponse now carries a next-hop per address family (via_ip_v4 and via_ip_v6). The daemon sets the next-hop for each family present among the routes, and the network plugin gives each route the next-hop of its own family. The deprecated single via is still populated and honored as a fallback, so a daemon and a plugin of mismatched versions keep routing single-family clusters. The default teleroute plugin tag is bumped to 0.5.0; a plugin built from this change must be published at that tag. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-06-12

Short-circuit local traffic to intercepted destinations When the handler of one intercept dials a cluster destination that is covered by another of the client's active intercepts (or its own), the connection round-tripped through the cluster only to arrive back at a local intercept handler. The root daemon now pipes such connections directly to the handler. The user daemon derives, from each active intercept in the snapshot, the workload identity, the intercepted container port and protocol, the service ClusterIP:port, and the local handler address, and pushes them to the root daemon with the new SetInterceptShortcuts RPC, where each push replaces the previous set. The root daemon matches outbound connections against the declared service addresses and, via its agent-pod snapshot, against the pod IPs of intercepted workloads, so all replicas are covered, including pods that appear after the intercept. A match creates a local pipe instead of a tunnel stream. The service cluster IPs are resolved by the traffic-manager when the intercept is prepared, and travel to the client in the new service_ips fields of PreparedIntercept and InterceptSpec. The manager also fills in the previously unset resolved service name. Clients therefore need no permission to read services. An old manager leaves the fields empty, which degrades the shortcuts to pod-IP matching only. The feature is enabled by default and controlled by the new client config setting intercept.localShortcut, also settable cluster-wide via the chart's client.intercept.localShortcut value. An old root daemon answers the new RPC with Unimplemented, which the user daemon tolerates, and an old user daemon never calls it, so version skew in any direction degrades to today's round-trip behavior. Closes #4125 Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-06-05

Merge branch 'release/v2' into fabricionl/ingest-namespace-flag Signed-off-by: Fabricio Neri <fabricio@frontec.ai>

2026-05-29

Support multi-namespace ingest Add --namespace support to the ingest and leave commands, mirroring the multi-namespace engagement feature added in v2.28.0 for intercept, wiretap, and replace (PR #4098). A single connection with mapped namespaces can now run simultaneous ingests in different namespaces, while preserving the connected namespace as the default when no engagement namespace is specified. Proto: - IngestIdentifier.namespace and IngestInfo.namespace in connector.proto - EnsureAgentRequest.namespace in manager.proto Manager: service.EnsureAgent uses the existing managedTargetNamespace helper to resolve and validate the requested namespace, falling back to the client's connected namespace when empty. Userd: ingestKey now includes namespace; Ingest() applies the same fallback and ActualNamespace validation as intercept.CanIntercept (verbatim error message). findIngest threads namespace through with auto-resolution when omitted. Handler-cleanup IDs gain an optional namespace component (workload/container/namespace), with the parser still accepting the legacy two-part form. CLI: --namespace/-n flag on ingest and on leave (leave needs it because ingests are identified by workload+container+namespace, not by a unique name). ingest.Info JSON/text output now includes Namespace. Tests: extended TestSession_findIngest with cross-namespace and ambiguity cases; added Test_MultiNamespaceIngests integration test mirroring Test_MultiNamespaceHTTPIntercepts. Signed-off-by: Fabricio Neri <fabricio@frontec.ai>

2026-05-25

feat(usg): anonymous usage reporting subsystem Add an opt-out anonymous usage-reporting subsystem that lets the CLI/user daemon emit one report per tracked command (cmd.connect, cmd.list, cmd.quit, cmd.version, plus session.end) and the traffic-manager emit a manager.boot report at startup. Reports carry only an installation UUID, OS/architecture, the binary version, a code-defined topic and a small map of safe-listed entries; they never carry cluster, namespace, workload, or address data. The CLI persists reports to an on-disk FIFO under the cache directory; the user daemon drains it and ships batches over gRPC to a configured collector. The traffic-manager uses an in-memory FIFO and runs the sender goroutine in-process. Both FIFOs evict the oldest entry on overflow so the most recent reports are always retained. Sender-side budget guards (truncation, MaxEntryCount, MaxBatchSize) keep a stray oversize value from getting a whole batch rejected. The root daemon now reports session-end telemetry to the user daemon via new fields on daemon.Activity (session_end, session_duration, outbound_tunnels, outbound_tunnel_errors, incoming_dials, incoming_dial_errors); the user daemon picks the terminal Activity up in cancelSession and emits a session.end usage report. LoadConfig deep-merges a new machine-wide config under filelocation.AppSystemConfigDir under the per-user file at the YAML level (so an administrator's usage.enabled=false in the system file can be overridden by an explicit user value matching the default), with the single-file pinned path used by the rootd preserved. The Helm chart gains a usage block (enabled / collectorAddress / insecure) that the manager deployment passes to the binary via env vars, plus the namespace-scoped RBAC needed for the traffic-manager-install ConfigMap. Integration tests are configured to never phone home by default. A new UsageReporting suite spins up a fake gRPC collector on the host, verifies host-from-cluster reachability via host.docker.internal, runs a real connect + intercept, and asserts that reports from both client and manager arrive end-to-end. Signed-off-by: Thomas Hallgren <thomas@tada.se>

feat(usg): anonymous usage reporting subsystem Add an opt-out anonymous usage-reporting subsystem that lets the CLI/user daemon emit one report per tracked command (cmd.connect, cmd.list, cmd.quit, cmd.version, plus session.end) and the traffic-manager emit a manager.boot report at startup. Reports carry only an installation UUID, OS/architecture, the binary version, a code-defined topic and a small map of safe-listed entries; they never carry cluster, namespace, workload, or address data. The CLI persists reports to an on-disk FIFO under the cache directory; the user daemon drains it and ships batches over gRPC to a configured collector. The traffic-manager uses an in-memory FIFO and runs the sender goroutine in-process. Both FIFOs evict the oldest entry on overflow so the most recent reports are always retained. Sender-side budget guards (truncation, MaxEntryCount, MaxBatchSize) keep a stray oversize value from getting a whole batch rejected. The root daemon now reports session-end telemetry to the user daemon via new fields on daemon.Activity (session_end, session_duration, outbound_tunnels, outbound_tunnel_errors, incoming_dials, incoming_dial_errors); the user daemon picks the terminal Activity up in cancelSession and emits a session.end usage report. LoadConfig deep-merges a new machine-wide config under filelocation.AppSystemConfigDir under the per-user file at the YAML level (so an administrator's usage.enabled=false in the system file can be overridden by an explicit user value matching the default), with the single-file pinned path used by the rootd preserved. The Helm chart gains a usage block (enabled / collectorAddress / insecure) that the manager deployment passes to the binary via env vars, plus the namespace-scoped RBAC needed for the traffic-manager-install ConfigMap. Integration tests are configured to never phone home by default. A new UsageReporting suite spins up a fake gRPC collector on the host, verifies host-from-cluster reachability via host.docker.internal, runs a real connect + intercept, and asserts that reports from both client and manager arrive end-to-end. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-04-10

Address PR feedback for multinamespace Signed-off-by: Breland Miley <breland@bdawg.org>

Support multi-namespace intercepts Signed-off-by: Breland Miley <breland@bdawg.org>

2026-01-19

Changes in response to the AI code-review Signed-off-by: Thomas Hallgren <thomas@tada.se>

Adjust CLI command to use the new AdminCommand mechanism. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add revoke to client Signed-off-by: Phan Duc <phan.duc@moneyforward.co.jp>

Add support for overriding intercepts owned by inactive clients Introduce the Helm chart setting `intercept.inactiveBlockTimeout` that controls the maximum amount of time an intercept may be held by a client that is unreachable or inactive. Once this timeout is exceeded, the intercept no longer blocks conflicting intercepts and may be automatically removed when another client attempts to create a conflicting intercept. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2026-01-14

Always pass kubeconfigs as kubeconfig-data Switch from writing the modified kubeconfig to a file in the user's home directory to passing its contents directly in the `kubeconfig-data` field. This removes the need for the daemon to access any home directories, enabling the systemd unit to use the stronger `ProtectHome=yes` (fully inaccessible) rather than `ProtectHome=read-only`. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Make the root daemon more suitable to run as a system managed daemon - Enhanced root daemon new `--managed` flag, which affects how the daemon responds to a `telepresence quit -s`. - Added "std" and "managed" as new predefined log file destinations. "std" splits log output to stdout and stderr. "managed" does the same but will refrain from adding timestamp and log level prefix. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-12-31

Merge branch 'release/v2.26' into thallgren/merge-2.26

2025-12-27

Use gRPC delta methods for efficient map updates Switch to gRPC delta methods where available to reduce client/server map update payloads by transmitting only changes instead of full snapshots. Implemented backward-compatible fallback to full snapshot streaming when delta methods are not supported. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-11-03

Use gRPC error instead of passing errors in return values. This commit changes how connect, intercept, and some other gRPC calls propagate errors to the caller so that all calls either return a proper result and nil, or no result at all and an error. Earlier, errors were often propagated in the result itself, leading to overly complex logic. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Refactor NetworkConfig and Cluster to simplify API This commit significantly refactors the NetworkConfig and Cluster structures to simplify the API by reducing explicit context passing. The Cluster struct now embeds a context instead of receiving it as a parameter, and many functions that previously took contexts now use the embedded context from the Cluster instance. Overall, these changes enhance maintainability and consistency across the codebase by centralizing context management within the Cluster type. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-10-31

w.i.p. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-10-28

w.i.p. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-10-04

Add a plaintext boolean to the intercept spec. This flag is intended for a future addition where the traffic-agent is capable of handling HTTP 2. Signed-off-by: Thomas Hallgren <thomas@tada.se>

RESTful API Service Reintroduced with HTTP Filtering Support The Telepresence RESTful API service has been restored with enhanced support for HTTP header and path filtering. This service enables workloads to programmatically query whether they should handle requests based on active intercepts. Added `--meta` flag allows attaching custom metadata to intercepts that can be retrieved through the API endpoints. The API server is now accessible via `TELEPRESENCE_API_HOST` and `TELEPRESENCE_API_PORT` environment variables in both cluster pods and local intercept handlers. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-10-03

RESTful API Service Reintroduced with HTTP Filtering Support The Telepresence RESTful API service has been restored with enhanced support for HTTP header and path filtering. This service enables workloads to programmatically query whether they should handle requests based on active intercepts. Added `--meta` flag allows attaching custom metadata to intercepts that can be retrieved through the API endpoints. The API server is now accessible via `TELEPRESENCE_API_HOST` and `TELEPRESENCE_API_PORT` environment variables in both cluster pods and local intercept handlers. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-09-26

feat(intercept): remove HttpMechanism field and update related logic for header filters Signed-off-by: Błażej Gruszka <blazej.gruszka@displate.com>

2025-09-25

feat(interceptor): add HTTP header and path filtering for HTTP intercepts - Introduced `header_filters` and `path_filters` fields in `InterceptSpec` to allow interception based on specific HTTP headers and path patterns. - Implemented `NewInterceptorWithMechanism` to create an HTTP-aware interceptor when the mechanism is set to "http". - Enhanced `tcp.forwardHTTPConn` to handle HTTP connections with the new filtering logic. - Added unit tests for `httpInterceptor` to validate the header and path filtering functionality. Signed-off-by: Błażej Gruszka <blazej.gruszka@displate.com>

2025-09-19

Fixes in response to Copilot review Signed-off-by: Thomas Hallgren <thomas@tada.se>

Drop the ManagerProxy that dispatches from root daemon to manager Root daemon speaks directly with the manager anyway, so the proxy is now redundant. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Remove client to traffic-agent tunneling via traffic-manager Signed-off-by: Thomas Hallgren <thomas@tada.se>

Enhance resilience of engagements during traffic-manager redeploys The telepresence client and traffic-agent now automatically reconnect to the traffic-manager after a restart. Upon reconnection, they share their current state, ensuring ongoing engagements remain uninterrupted. This improvement minimizes user impact during traffic-manager upgrades. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Remove gRPC functions related to Ambassador Cloud. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-09-18

Remove snapshot management. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Misc clean-up and added rollout restart functionality. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-09-15

Remove client to traffic-agent tunneling via traffic-manager Signed-off-by: Thomas Hallgren <thomas@tada.se>

Remove gRPC functions related to Ambassador Cloud. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-09-14

Add support for IPv6 and dual-stack to `telepresence connect --docker` Telepresence now supports using `telepresence connect --docker` together with Kubernetes single-stack IPv4 networking, single-stack IPv6 networking, or dual-stack networking with both network families. Both are enabled by default, but can be disabled by setting the `client.docker.enableIPv4` or `client.docker.enableIPv6` to `false` in the Helm chart, or by using the corresponding settings `docker.enableIPv4` or `docker.enableIPv6` in the client configuration file. The new dual-stack support requires the teleroute network plugin 0.4.0 or later. The client will install this version automatically unless you work in an air-gapped environment. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add support for IPv6 and dual-stack to `telepresence connect --docker` Telepresence now supports using `telepresence connect --docker` together with Kubernetes single-stack IPv4 networking, single-stack IPv6 networking, or dual-stack networking with both network families. Both are enabled by default, but can be disabled by setting the `client.docker.enableIPv4` or `client.docker.enableIPv6` to `false` in the Helm chart, or by using the corresponding settings `docker.enableIPv4` or `docker.enableIPv6` in the client configuration file. The new dual-stack support requires the teleroute network plugin 0.4.0 or later. The client will install this version automatically unless you work in an air-gapped environment. Signed-off-by: Thomas Hallgren <thomas@tada.se>

More efficient DNS handling in the traffic-manager Telepresence will no longer send DNS queries for A and AAAA records to the traffic-manager. Instead, it will send a single query for the name and then derive the record type from the type of IP address (IPv4 or IPv6) in the response. This reduces the number of DNS queries sent to the cluster's DNS server and makes the behavior more consistent with the `net.LookupNetIP` function in the Go standard library, which the traffic-manager ultimately uses. The lookups will now be performed exclusively by the traffic-manager, never by the traffic-agent. This means that traffic-agents with special DNS configurations might stop working. If this is a problem, the old behavior can be restored by setting the `client.dns.useComplexLookup` parameter in the Helm chart or the `dns.useComplexLookup` parameter in the client configuration file. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-09-13

Add support for IPv6 and dual-stack to `telepresence connect --docker` Telepresence now supports using `telepresence connect --docker` together with Kubernetes single-stack IPv4 networking, single-stack IPv6 networking, or dual-stack networking with both network families. Both are enabled by default, but can be disabled by setting the `client.docker.enableIPv4` or `client.docker.enableIPv6` to `false` in the Helm chart, or by using the corresponding settings `docker.enableIPv4` or `docker.enableIPv6` in the client configuration file. The new dual-stack support requires the teleroute network plugin 0.4.0 or later. The client will install this version automatically unless you work in an air-gapped environment. Signed-off-by: Thomas Hallgren <thomas@tada.se>

More efficient DNS handling in the traffic-manager Telepresence will no longer send DNS queries for A and AAAA records to the traffic-manager. Instead, it will send a single query for the name and then derive the record type from the type of IP address (IPv4 or IPv6) in the response. This reduces the number of DNS queries sent to the cluster's DNS server and makes the behavior more consistent with the `net.LookupNetIP` function in the Go standard library, which the traffic-manager ultimately uses. The lookups will now be performed exclusively by the traffic-manager, never by the traffic-agent. This means that traffic-agents with special DNS configurations might stop working. If this is a problem, the old behavior can be restored by setting the `client.dns.useComplexLookup` parameter in the Helm chart or the `dns.useComplexLookup` parameter in the client configuration file. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-09-12

More efficient DNS handling in the traffic-manager Telepresence will no longer send DNS queries for A and AAAA records to the traffic-manager. Instead, it will send a single query for the name and then derive the record type from the type of IP address (IPv4 or IPv6) in the response. This reduces the number of DNS queries sent to the cluster's DNS server and makes the behavior more consistent with the `net.LookupNetIP` function in the Go standard library, which the traffic-manager ultimately uses. The lookups will now be performed exclusively by the traffic-manager, never by the traffic-agent. This means that traffic-agents with special DNS configurations might stop working. If this is a problem, the old behavior can be restored by setting the `client.dns.useComplexLookup` parameter in the Helm chart or the `dns.useComplexLookup` parameter in the client configuration file. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-08-02

Introducing Port Rerouting The telepresence connect command introduces two new flags: The `--reroute-remote <host>:<port>:<new-port>[/{tcp|udp}]` flag, allowing users to remap service ports. This flag redirects requests sent to `<host>:<new-port>` to `<host>:<port>` within the Telepresence VIF The `--reroute-local <local-port>:<host>:<port>[/{tcp|udp}]` flag, allowing users to redirect requests sent to ports on localhost to arbitrary service ports. This feature enables requests sent to `localhost:<local-port>` to be redirected to `<host:port>`. Both flags can be repeated. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Introducing Port Rerouting The telepresence connect command introduces two new flags: The `--reroute-remote <host>:<port>:<new-port>[/{tcp|udp}]` flag, allowing users to remap service ports. This flag redirects requests sent to `<host>:<new-port>` to `<host>:<port>` within the Telepresence VIF The `--reroute-local <local-port>:<host>:<port>[/{tcp|udp}]` flag, allowing users to redirect requests sent to ports on localhost to arbitrary service ports. This feature enables requests sent to `localhost:<local-port>` to be redirected to `<host:port>`. Both flags can be repeated. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-07-29

Introducing Service Port Remapping The telepresence connect command introduces a new `--port-map <host:port>:<to-port>[/{tcp|udp}]` flag, allowing users to remap service ports. This feature enables requests sent to `<host:port>` to be redirected to `<host:to-port>` within the Telepresence VIF, offering a flexible way to configure port connectivity. The flag can be repeated. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-07-18

Serve up a web-page with telepresence serve. A new `telepresence serve <service>` command was added that starts a web browser on the specified service. The command is especially useful when used in combination with `telepresence connect --docker` because it will then expose the given service on a random port on localhost. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-07-15

Add support for Docker Compose. Telepresence now supports integration with Docker Compose. It connects to and interacts with cluster resources by utilizing `x-<engagement>` extensions within a Docker Compose specification. These extensions configure your local services to effectively act as handlers for Telepresence connections, providing them with the necessary access to the traffic, volumes, and environment of the engaged container. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-07-11

Add support for Docker Compose. Telepresence now supports integration with Docker Compose. It connects to and interacts with cluster resources by utilizing `x-<engagement>` extensions within a Docker Compose specification. These extensions configure your local services to effectively act as handlers for Telepresence connections, providing them with the necessary access to the traffic, volumes, and environment of the engaged container. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-07-08

Add support for Docker Compose. Telepresence now supports integration with Docker Compose. It connects to and interacts with cluster resources by utilizing `x-<engagement>` extensions within a Docker Compose specification. These extensions configure your local services to effectively act as handlers for Telepresence connections, providing them with the necessary access to the traffic, volumes, and environment of the engaged container. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-06-28

Add support for Docker Compose. Telepresence now supports integration with Docker Compose. It connects to and interacts with cluster resources by utilizing `x-<engagement>` extensions within a Docker Compose specification. These extensions configure your local services to effectively act as handlers for Telepresence connections, providing them with the necessary access to the traffic, volumes, and environment of the engaged container. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-06-18

Add support for Docker Compose. Telepresence now supports integration with Docker Compose. It connects to and interacts with cluster resources by utilizing `x-<engagement>` extensions within a Docker Compose specification. These extensions configure your local services to effectively act as handlers for Telepresence connections, providing them with the necessary access to the traffic, volumes, and environment of the engaged container. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-06-15

Add support for Docker Compose. Telepresence now supports integration with Docker Compose. It connects to and interacts with cluster resources by utilizing `x-<engagement>` extensions within a Docker Compose specification. These extensions configure your local services to effectively act as handlers for Telepresence connections, providing them with the necessary access to the traffic, volumes, and environment of the engaged container. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-06-11

Add Telepresence Docker Network Plugin "Teleroute" The new Teleroute plugin makes it possible for containers to use the Telepresence daemon's VIF without having to change their network mode, i.e. a `--network container:<daemon container>` is no longer needed. Instead, a container can use a custom network created when the Telepresence daemon connects to the cluster. This network uses the new driver "teleroute" which is provided by Telepresence. With the Teleroute Docker network plugin in place, there's no longer a need for special handling of network related docker flags, and the following changes have been made: 1. The Teleroute Docker network driver will be installed unless it is already present. 2. A Teleroute network will be created when starting the Telepresence daemon as a container. This network will then communicate with that container and expose the same CIDRs as the daemon's VIF. 3. A container started with `telepresence curl`, or `telepresence {ingest|intercept|replace|wiretap} --docker-{run|build|debug}` will no longer change its network mode using `--network container:<daemon container>`, instead it will use `--network <name of teleroute network>`. 4. As a consequence of #3, published ports and other networks that are added no longer need special handling using socat containers, so all of that has been removed. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add the ability to use a name for the target host. Knowing the IP of the local container that acts as the handler service for an intercept, replace, or wiretap is not possible until the container has been started. This commit introduces the concept of target host synthetic IP. A named target host will be replaced by a random synthesized IPv6 IP when the engagement is initialized. Later, when the traffic-agent container dials this IP, the original name will be found and resolved into an IP, thus deferring the name resolution until an actual request is made to the engaged pod. This allows the engagement to be created before the creation of the handler service, and removes the need for the user to use IP addresses. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add Telepresence Docker Network Plugin "Teleroute" The new Teleroute plugin makes it possible for containers to use the Telepresence daemon's VIF without having to change their network mode, i.e. a `--network container:<daemon container>` is no longer needed. Instead, a container can use a custom network created when the Telepresence daemon connects to the cluster. This network uses the new driver "teleroute" which is provided by Telepresence. With the Teleroute Docker network plugin in place, there's no longer a need for special handling of network related docker flags, and the following changes have been made: 1. The Teleroute Docker network driver will be installed unless it is already present. 2. A Teleroute network will be created when starting the Telepresence daemon as a container. This network will then communicate with that container and expose the same CIDRs as the daemon's VIF. 3. A container started with `telepresence curl`, or `telepresence {ingest|intercept|replace|wiretap} --docker-{run|build|debug}` will no longer change its network mode using `--network container:<daemon container>`, instead it will use `--network <name of teleroute network>`. 4. As a consequence of #3, published ports and other networks that are added no longer need special handling using socat containers, so all of that has been removed. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-06-10

Add Telepresence Docker Network Plugin "Teleroute" The new Teleroute plugin makes it possible for containers to use the Telepresence daemon's VIF without having to change their network mode, i.e. a `--network container:<daemon container>` is no longer needed. Instead, a container can use a custom network created when the Telepresence daemon connects to the cluster. This network uses the new driver "teleroute" which is provided by Telepresence. With the Teleroute Docker network plugin in place, there's no longer a need for special handling of network related docker flags, and the following changes have been made: 1. The Teleroute Docker network driver will be installed unless it is already present. 2. A Teleroute network will be created when starting the Telepresence daemon as a container. This network will then communicate with that container and expose the same CIDRs as the daemon's VIF. 3. A container started with `telepresence curl`, or `telepresence {ingest|intercept|replace|wiretap} --docker-{run|build|debug}` will no longer change its network mode using `--network container:<daemon container>`, instead it will use `--network <name of teleroute network>`. 4. As a consequence of #3, published ports and other networks that are added no longer need special handling using socat containers, so all of that has been removed. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add the ability to use a name for the target host. Knowing the IP of the local container that acts as the handler service for an intercept, replace, or wiretap is not possible until the container has been started. This commit introduces the concept of target host synthetic IP. A named target host will be replaced by a random synthesized IPv6 IP when the engagement is initialized. Later, when the traffic-agent container dials this IP, the original name will be found and resolved into an IP, thus deferring the name resolution until an actual request is made to the engaged pod. This allows the engagement to be created before the creation of the handler service, and removes the need for the user to use IP addresses. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-06-09

Add Telepresence Docker Network Plugin "Teleroute" The new Teleroute plugin makes it possible for containers to use the Telepresence daemon's VIF without having to change their network mode, i.e. a `--network container:<daemon container>` is no longer needed. Instead, a container can use a custom network created when the Telepresence daemon connects to the cluster. This network uses the new driver "teleroute" which is provided by Telepresence. With the Teleroute Docker network plugin in place, there's no longer a need for special handling of network related docker flags, and the following changes have been made: 1. The Teleroute Docker network driver will be installed unless it is already present. 2. A Teleroute network will be created when starting the Telepresence daemon as a container. This network will then communicate with that container and expose the same CIDRs as the daemon's VIF. 3. A container started with `telepresence curl`, or `telepresence {ingest|intercept|replace|wiretap} --docker-{run|build|debug}` will no longer change its network mode using `--network container:<daemon container>`, instead it will use `--network <name of teleroute network>`. 4. As a consequence of #3, published ports and other networks that are added no longer need special handling using socat containers, so all of that has been removed. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-06-08

Add Telepresence Docker Network Plugin "Teleroute" The new Teleroute plugin makes it possible for containers to use the Telepresence daemon's VIF without having to change their network mode, i.e. a `--network container:<daemon container>` is no longer needed. Instead, a container can use a custom network created when the Telepresence daemon connects to the cluster. This network uses the new driver "teleroute" which is provided by Telepresence. With the Teleroute Docker network plugin in place, there's no longer a need for special handling of network related docker flags, and the following changes have been made: 1. The Teleroute Docker network driver will be installed unless it is already present. 2. A Teleroute network will be created when starting the Telepresence daemon as a container. This network will then communicate with that container and expose the same CIDRs as the daemon's VIF. 3. A container started with `telepresence curl`, or `telepresence {ingest|intercept|replace|wiretap} --docker-{run|build|debug}` will no longer change its network mode using `--network container:<daemon container>`, instead it will use `--network <name of teleroute network>`. 4. As a consequence of #3, published ports and other networks that are added no longer need special handling using socat containers, so all of that has been removed. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-06-07

Add Telepresence Docker Network Plugin "Teleroute" The new Teleroute plugin makes it possible for containers to use the Telepresence daemon's VIF without having to change their network mode, i.e. a `--network container:<daemon container>` is no longer needed. Instead, a container can use a custom network created when the Telepresence daemon connects to the cluster. This network uses the new driver "teleroute" which is provided by Telepresence. With the Teleroute Docker network plugin in place, there's no longer a need for special handling of network related docker flags, and the following changes have been made: 1. The Teleroute Docker network driver will be installed unless it is already present. 2. A Teleroute network will be created when starting the Telepresence daemon as a container. This network will then communicate with that container and expose the same CIDRs as the daemon's VIF. 3. A container started with `telepresence curl`, or `telepresence {ingest|intercept|replace|wiretap} --docker-{run|build|debug}` will no longer change its network mode using `--network container:<daemon container>`, instead it will use `--network <name of teleroute network>`. 4. As a consequence of #3, published ports and other networks that are added no longer need special handling using socat containers, so all of that has been removed. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add the ability to use a name for the target host. Knowing the IP of the local container that acts as the handler service for an intercept, replace, or wiretap is not possible until the container has been started. This commit introduces the concept of target host synthetic IP. A named target host will be replaced by a random synthesized IPv6 IP when the engagement is initialized. Later, when the traffic-agent container dials this IP, the original name will be found and resolved into an IP, thus deferring the name resolution until an actual request is made to the engaged pod. This allows the engagement to be created before the creation of the handler service, and removes the need for the user to use IP addresses. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-06-06

Network plugin work to be merged down Signed-off-by: Thomas Hallgren <thomas@tada.se>

w.i.p. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Functional step 1 (daemon container has no DNS yet) Signed-off-by: Thomas Hallgren <thomas@tada.se>

Test with moving veth to plugin Signed-off-by: Thomas Hallgren <thomas@tada.se>

Test single bridge 1 Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-06-05

w.i.p. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Functional step 1 (daemon container has no DNS yet) Signed-off-by: Thomas Hallgren <thomas@tada.se>

Network plugin work to be merged down Signed-off-by: Thomas Hallgren <thomas@tada.se>

Test with moving veth to plugin Signed-off-by: Thomas Hallgren <thomas@tada.se>

Fix bad neighbor issue Signed-off-by: Thomas Hallgren <thomas@tada.se>

Test single bridge 1 Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add the ability to use a name for the target host. Knowing the IP of the local container that acts as the handler service for an intercept, replace, or wiretap is not possible until the container has been started. This commit introduces the concept of target host synthetic IP. A named target host will be replaced by a random synthesized IPv6 IP when the engagement is initialized. Later, when the traffic-agent container dials this IP, the original name will be found and resolved into an IP, thus deferring the name resolution until an actual request is made to the engaged pod. This allows the engagement to be created before the creation of the handler service, and removes the need for the user to use IP addresses. Signed-off-by: Thomas Hallgren <thomas@tada.se>