Proto commits in telepresenceio/telepresence

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

2026-06-16

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>

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>

The documentation is generated from this commit.

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

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>

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>

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>

Remove client to traffic-agent tunneling via traffic-manager 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>

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

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

Network plugin work to be merged down 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 single bridge 1 Signed-off-by: Thomas Hallgren <thomas@tada.se>

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

2025-06-05

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

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

Add Teleroute network driver. Signed-off-by: Thomas Hallgren <thomas@tada.se>

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

Fix bad neighbor issue 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>

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

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

2025-06-03

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

2025-05-31

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

2025-05-30

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

2025-05-29

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

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

Fix bad neighbor issue 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 Teleroute network driver. Signed-off-by: Thomas Hallgren <thomas@tada.se>

Merge branch 'release/v2.22' into release/v2

2025-05-27

Unable to correctly determine service CIDR with Kubernetes >= 1.33 Starting with Kubernetes 1.33, the strategy of extracting the cluster's service CIDR from an error message no longer works because the error message has changed. The root cause for this is that Kubernetes introduced the ability to use [Multiple Service CIDRs](https://gist.github.com/aojea/c20eb117bf1c1214f8bba26c495be9c7). Since `ServiceCIDR` is now a resource, it can be easily retrieved (and modified) using standard Kubernetes client API calls, and this is what the traffic manager will use going forward. The fix required an addition to the traffic-manager's RBAC, granting it sufficient permissions to list `networking.k8s.io/servicecidrs`. A future enhancement will allow the traffic manager to watch for service CIDR changes. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-05-06

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

2025-05-04

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

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

2025-04-26

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 Teleroute network driver. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-04-25

Lint fixes. 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>

rewire docker-run Signed-off-by: Thomas Hallgren <thomas@tada.se>

Add Teleroute network driver. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-04-14

W.I.P. Telepresence Docker Network Plugin Signed-off-by: Thomas Hallgren <thomas@tada.se>

Update module dependencies. Signed-off-by: Thomas Hallgren <thomas@tada.se>

W.I.P. Telepresence Docker Network Plugin Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-03-26

Add a telepresence wiretap command. A wiretap is a read-only form of an intercept. The original container will still receive the wiretapped traffic, and a copy of the traffic is sent to the client. Writes on the client connection are discarded. Similar to an ingest, a wiretap will always enforce read-only status on all volume mounts, and since the wiretap then is completely read-only, there's no limit to how many simultaneous wiretaps that can be served. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-03-11

Decouple downloads from getambassador.io Changes download links to point directly to GitHub instead of being forwarded from getambassador.io. Signed-off-by: Thomas Hallgren <thomas@tada.se>

2025-03-08

Decouple downloads from getambassador.io Changes download links to point directly to GitHub instead of being forwarded from getambassador.io. Signed-off-by: Thomas Hallgren <thomas@tada.se>