-
-
Notifications
You must be signed in to change notification settings - Fork 565
Expand file tree
/
Copy pathCHANGELOG.yml
More file actions
2187 lines (2121 loc) · 140 KB
/
CHANGELOG.yml
File metadata and controls
2187 lines (2121 loc) · 140 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
# The YAML in this file should contain:
#
# items: An array of releases with the following attributes:
# - version: The (optional) version number of the release, if applicable.
# - date: >-
# The date of the release in the format YYYY-MM-DD.
# If the date is (SUPERSEDED), then the release didn't happen, which means
# that its notes belong to the next release.
# - notes: An array of noteworthy changes included in the release, each having the following attributes:
# - type: The type of change, one of `bugfix`, `feature`, `security` or `change`.
# - title: A short title of the noteworthy change.
# - body: >-
# Two or three sentences describing the change and why it
# is noteworthy. This is HTML, not plain text or
# markdown. It is handy to use YAML's ">-" feature to
# allow line-wrapping.
# - image: >-
# The URL of an image that visually represents the
# noteworthy change. This path is relative to the
# `release-notes` directory; if this file is
# `FOO/releaseNotes.yml`, then the image paths are
# relative to `FOO/release-notes/`.
# - docs: The path to the documentation page where additional information can be found.
#
# For older changes, see CHANGELOG.OLD.md
items:
- version: 2.27.0
date: 2026-02-28
notes:
- type: feature
title: Add macOS package installer with root daemon as a system service
body: >-
A new macOS package installer (.pkg) is now available that installs Telepresence with the root daemon
configured as a launchd service. This eliminates the need for elevated privileges when using Telepresence,
as the daemon starts automatically at boot and runs in the background. Available for both Intel (amd64)
and Apple Silicon (arm64) Macs.
docs: install/client
- type: feature
title: Add Linux package installers with root daemon as a system service
body: >-
New Linux package installers (.deb for Debian/Ubuntu and .rpm for Fedora/RHEL) are now available that
install Telepresence with the root daemon configured as a systemd service. This eliminates the need for
elevated privileges when using Telepresence, as the service is enabled and started automatically during
installation. Available for both amd64 and arm64 architectures.
docs: install/client
- type: feature
title: Add Windows installer with root daemon as a system service
body: >-
A new Windows installer (.exe) is now available that installs Telepresence with the root daemon configured
as a Windows service. The installer bundles WinFSP and SSHFS-Win dependencies for volume mount support,
adds Telepresence to the system PATH, and optionally installs the TelepresenceDaemon service. This eliminates
the need for elevated privileges when using Telepresence. Currently available for amd64 architecture only
due to dependency constraints.
docs: install/client
- type: feature
title: Add route-controller DaemonSet to prevent routing loops on local clusters
body: >-
A new optional <code>route-controller</code> DaemonSet can be deployed alongside the traffic-manager
on local Kubernetes clusters (Kind, minikube, k3d, Docker Desktop) to prevent routing loops caused by
deleted or non-existent service ClusterIPs. It installs an iptables <code>FORWARD</code> chain
<code>DROP</code> rule for the service CIDR on every node, and adds per-IP kernel blackhole routes
when a Service is deleted. Enable it with <code>routeController.enabled=true</code> in the Helm chart.
docs: reference/route-controller
- type: feature
title: Automatic cache cleanup on version change
body: >-
Telepresence now tracks its version in a version.json file in the cache directory. When the CLI detects
that the major.minor version differs from the running binary, it automatically quits running daemons and
clears stale cache entries (preserving logs). This prevents issues caused by leftover cache files from a
previous version. Patch and pre-release version changes do not trigger a cache cleanup.
- type: bugfix
title: Cluster DNS not injected into containers started by telepresence compose
body: >-
When using <code>telepresence compose up</code>, cluster hostnames did not resolve inside the compose
container because the daemon DNS IP and the tel2-search DNS search domain were not being added to the
generated compose spec. DNS and dns_search are now correctly set for all engaged compose services.
docs: https://github.com/telepresenceio/telepresence/issues/4053
- version: 2.26.2
date: 2026-02-14
notes:
- type: bugfix
title: Dial 127.0.0.1 instead of 0.0.0.0 when connecting to local daemons
body: >-
When a VPN routes all private network addresses, dialing 0.0.0.0 gets routed through the VPN instead
of reaching the locally running daemon. This causes Telepresence to report that no daemon is running
even though the processes are active and listening. The client now dials 127.0.0.1 explicitly, and
the Docker-published daemon port is bound to 127.0.0.1 to match.
docs: https://github.com/telepresenceio/telepresence/issues/4048
- type: bugfix
title: Fix HTTP intercepts via telepresence compose failing when httpFilters or httpPaths are set
body: >-
The compose extension set HeaderFilters and PathFilters on the intercept spec but left the mechanism as "tcp".
This caused the traffic manager to reject the intercept with "global TCP/UDP intercepts are disabled".
The mechanism is now correctly switched to "http" when any HTTP filters are specified, matching the behavior
of the CLI intercept command.
- type: bugfix
title: Fix "root daemon is embedded" error on Windows elevated terminals
body: >-
When running Telepresence in an elevated (administrator) terminal on Windows, commands like connect and
loglevel failed with "root daemon is embedded". The user daemon now correctly delegates to the in-process
root daemon session instead of returning an error.
docs: https://github.com/telepresenceio/telepresence/issues/4049
- type: bugfix
title: Fix h2c (HTTP/2 cleartext) prior knowledge not working on transport
body: >-
Since Go 1.24, having both HTTP1 and UnencryptedHTTP2 enabled on an HTTP transport causes Go to
default to HTTP/1.1 instead of using h2c prior knowledge. The transport now explicitly disables
HTTP1 when UnencryptedHTTP2 is enabled, fixing h2c communication for both the default forwarding
handler and intercepted traffic.
docs: https://github.com/telepresenceio/telepresence/issues/4056
- version: 2.26.1
date: 2026-01-26
notes:
- type: bugfix
title: Add support for "warning" as an alias for "warn" in log levels
body: >-
The "warning" alias for "warn" was the only acceptable value in the Helm chart, yet the traffic manager didn't accept it. This is
now fixed so that both names are accepted by the Helm chart and by the traffic manager.
docs: https://github.com/telepresenceio/telepresence/issues/4043
- version: 2.26.0
date: 2026-01-23
notes:
- type: feature
title: Add ability for cluster admins to revoke other users' intercepts.
body: |-
The traffic-manager can now execute commands defined in the traffic-manager ConfigMap. As a result, clients that are authorized to
update this ConfigMap can issue those commands.
This mechanism lays the groundwork for distinguishing administrators from regular users in Telepresence. Administrators can be
granted RBAC permissions that allow them to update the traffic-manager ConfigMap, while regular users cannot.
The new command, `telepresence revoke <intercept-id>`, uses this mechanism to revoke the intercept associated with the specified
ID.
docs: reference/engagements/conflicts
- type: feature
title: Add support for overriding intercepts owned by inactive clients
body: >-
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.
docs: reference/engagements/conflicts
- type: feature
title: Add support for sudo-rs
body: >-
Telepresence now supports running the root daemon using `sudo-rs`. This is necessary on Ubuntu where `sudo-rs` has become the
default for `sudo`.
- type: feature
title: Add configuration to disable global TCP/UDP intercepts
body: >-
A new Helm chart configuration option `intercept.allowGlobalIntercepts` has been added to control
whether global TCP/UDP intercepts are permitted. When set to `false`, only HTTP intercepts with
header or path filters are allowed, preventing users from creating global intercepts that block
other developers from intercepting the same port. This is particularly useful in shared development
environments where multiple developers need to work on the same service simultaneously. The setting
defaults to `true` to maintain full backward compatibility with existing deployments. When a user
attempts to create a global intercept while the setting is disabled, they receive a helpful error
message suggesting the use of `--http-header` or `--http-path-*` flags for HTTP-filtered intercepts.
docs: reference/cluster_config#restricting_global_intercepts
- type: feature
title: Enhanced Traffic Manager Startup Reliability
body: |-
The Traffic Manager deployment now includes a `startupProbe` that accurately detects when the service is fully initialized and
ready to handle traffic. This enhancement brings the following benefits:
- **Prevents Premature Traffic Routing**: The manager only reports itself as ready after all configurations are loaded,
eliminating potential race conditions
- **Smoother Upgrades and Rollouts**: Deployment orchestration tools can reliably determine when the Traffic Manager is
operational, improving overall installation stability
This change is particularly beneficial in large clusters or complex networking environments where initialization may take longer
than expected.
- type: feature
title: Support customizable daemon config file
body: >-
The config file for Telepresence is now configurable through the command-line flag `--config`.
The `--config <agent config>` flag of the `telepresence genyaml` command was renamed to `--agent` to avoid confusion.
- type: feature
title: Support customizable daemon log file paths
body: >-
Log file paths for the Telepresence daemons are now configurable through the command-line flag `--logfile`
that denotes a custom log file location or redirect of the log output to stdout/stderr. Two new log-level
configuration entries for `cli` and `kubeAuthDaemon` are also introduced, expanding the existing log-level
controls beyond just `userDaemon` and `rootDaemon`.
- type: feature
title: Add ability to exclude or include modifications made by other injectors when injecting the traffic agent.
body: >-
The Traffic Agent now has a new configuration option `agentInjector.mutationAware` that can be set to `false` to exclude
modifications made by other injectors when injecting the traffic agent. Setting `agentInjector.mutationAware=true` requires
`agentInjector.webhook.reinvocationPolicy=IfNeeded`. The default setting is `true`.
- type: feature
title: Add ability to disable the Traffic Agent's HTTP2/Clear-Text probing.
body: >-
The Traffic Agent now has a new configuration option `agent.enableH2cProbing` that can be set to `false` to disable the
HTTP2/Clear-Text probing. The default setting is `true` to preserve backwards compatibility, but this will be changed to `false`
in a future release.
- type: feature
title: Add ability to configure the Traffic Agent's retry interval for watching intercepts.
body: >-
The Traffic Agent's retry interval when it establishes its watcher for intercepts is now configurable using the Helm chart value
`agent.watchRetryInterval`. The default retry interval was also increased from 2 seconds to 10 seconds to improve resilience when
connections to the traffic manager are lost.
- type: feature
title: Make traffic-agent consumption metrics reporting optional.
body: >-
Metrics reporting for the traffic-agent can now be optionally enabled or disabled via the `agent.enableConsumptionMetrics` Helm
chart value. The traffic-agent metrics will also be completely disabled when the Helm chart value `prometheus.port` is unset or
zero.
This change is intended to reduce the amount of unnecessary traffic generated by the traffic-agent when consumption metrics
reporting is of no interest to the user.
- type: feature
title: Improved efficiency of traffic manager map updates.
body: >-
The watchable map has been refactored into a client/server model that supports delta-based updates. Where supported, gRPC now
transmits only incremental changes instead of full snapshots, significantly reducing payload sizes. This improvement is especially
important for large clusters, where full snapshots can be sizable and costly to transmit. Full snapshot streaming remains
available as a backward-compatible fallback for clients that do not support delta methods.
- type: change
title: Use TCP/IP instead of Unix sockets for all communication between local processes.
body: >-
Telepresence now uses TCP/IP sockets for all communication between local processes. This change reduces the
risk of socket-related errors caused by lingering sockets from previous Telepresence sessions. It also
eliminates the difficulties of using Unix sockets for communication between a system service and user
processes on Windows.
- type: change
title: Don't allow connect with --docker when client is configured with intercept.useFtp=true
body: |-
The `--docker` flag is not allowed when the client is configured with `intercept.useFtp=true` and an error is now generated
instantly by the `telepresence connect --docker` command.
The docker volume plugin cannot use FTP because it requires two ports: a fixed control port that Telepresence can proxy, and a
dynamic data port (randomly chosen during connection) that Telepresence cannot proxy on-demand. The port-forwarder only forwards
pre-configured ports and doesn't understand FTP's protocol. Consequently, FTP isn't allowed in this scenario. If it was, then when
an FTP server tells the client to use an unpredictable second port for file transfers, Telepresence would block it—causing the
connection to fail every time.
- type: change
title: Better names for the Telepresence Daemons
body: |-
Using the name xxx-foreground isn't very intuitive when talking about daemon processes. Yes, the command, when issued in a
terminal, will start the daemon in foreground so the names of the commands does have some logic to them, but then again, starting
in the foreground is the default behavior of any command. And when the same command is started from the CLI, it will be started in
the background, despite its name.
The daemons are therefore now renamed:
- connector-foreground => userd
- daemon-foreground => rootd
- kubeauth-foreground => kubeauthd
This also affects the Telepresence hidden CLI commands `telepresence daemon-foreground` and `telepresence connector-foreground`.
- type: bugfix
title: Add retry logic for tunnel connection attempts
body: >-
The tunnel dialer now uses a backoff-based retry mechanism when establishing connections. This ensures that dialing attempts for
both TCP and UDP protocols persist if the target IP is not immediately ready to receive requests.
- type: bugfix
title: Retry mechanism for client tunnel creation
body: >-
The traffic agent now includes a backoff-based retry mechanism when establishing tunnel streams to a client. This prevents
"no dial watcher" connection failures caused by a race condition where the tunnel request arrives before the client has fully
initialized its communication channel.
- type: bugfix
title: Fix "close of closed channel" panic in the root daemon process.
body: >-
The root daemon process would sometimes panic with "close of closed channel" due to a race condition in the DNS cache logic.
This issue has been fixed.
- version: 2.25.2
date: 2025-12-26
notes:
- type: bugfix
title: Ensure that the exit code from a docker command becomes the exit code of the Telepresence command.
body: >-
When running a Docker command using `telepresence docker-run` or `telepresence curl`, the exit code would be 1 for all non-zero
exit codes from the Docker command. This has been fixed so that the exit code from the Docker command becomes the exit code of the
Telepresence command.
- type: bugfix
title: Fix a bug causing truncation of command text when generating external command help.
body: >-
The Telepresence CLI would truncate the command text when generating help for external commands such as `docker compose` that
had text spanning more than one line. This has been fixed so that the full command text is displayed.
- type: bugfix
title: Fix schema for agent.image.pullSecrets
body: >-
The `agent.image.pullSecrets` is referenced by the helm chart's deployment.yaml but was previously disallowed by the schema file.
- version: 2.25.1
date: 2025-11-10
notes:
- type: bugfix
title: Volumes did not mount correctly when using `telepresence connect --docker` when Docker had IPv6 enabled.
body: >-
Telepresence failed to mount volumes after connecting with `telepresence connect --docker` when Docker Engine had IPv6 enabled in
its default bridge network. Disabling IPv6 in the Telepresence client configuration did not resolve the issue. This was fixed in
Telepresence Volume Plugin "telemount" version 0.3.2, which circumvented a [bug in sshfs](https://github.com/libfuse/sshfs/issues/335).
Additionally, the volume plugin will no longer use IPv6 when the client configuration `docker.enableIPv6` is set to `false`.
- type: bugfix
title: Remove unnecessary setcap from traffic binary
body: >-
The setcap capability (cap_net_bind_service) was removed from the traffic binary build process.
This capability was originally added to allow the binary to bind to privileged ports, specifically
port 443 for the mutating webhook. Since version 2.24.0, the default mutating webhook port was
changed to 8443 (a non-privileged port), making this capability unnecessary. Removing it simplifies
the build process and reduces the security surface area.
- version: 2.25.0
date: 2025-10-16
notes:
- type: feature
title: HTTP Intercepts with HTTP header and path filtering
body: |-
Telepresence now supports HTTP Intercepts, enabling fine-grained HTTP traffic filtering for intercepts.
Users can intercept only specific HTTP requests based on headers and URL paths using the new `--http-header`,
`--http-path-prefix`, `--http-path-equal`, and `--http-path-regex` flags. This allows multiple developers
to work on the same service simultaneously by intercepting only their specific traffic patterns, rather than
intercepting all traffic to a service.
**Routing Precedence Model**: Header-based intercepts take priority over path-only intercepts. When multiple
intercepts are active on the same workload, requests are evaluated against header-based filters first, then
path-only filters. This enables different developers to use header-based personal intercepts (e.g.,
`x-user=alice`) while others use path-based intercepts (e.g., `/admin/*`) without conflicts.
**Conflict Detection**: Intercepts conflict only when their filters would route the same traffic to different
destinations. Key rules:
- Different header values (e.g., `X-User=adam` vs `X-User=bertil`) do NOT conflict
- Header filters use subset logic: `X-User=adam` conflicts with `X-User=adam, X-Session=123` (first is subset)
- Same headers with different paths do NOT conflict: `X-User=adam + /api/*` vs `X-User=adam + /admin/*`
- Path-only intercepts operate at a lower priority tier than header-based intercepts
The feature maintains full backward compatibility with existing TCP intercepts.
docs: howtos/engage#intercept-your-application
- type: feature
title: TLS/mTLS Intercept Support
body: |-
Support was added for HTTP-filtered intercepts on applications using TLS/mTLS encryption. The new functionality enables
Telepresence to decrypt and inspect encrypted traffic by accessing TLS certificates, facilitating debugging and testing of secure
applications.
Certificates can be accessed via mounted volumes or Kubernetes secrets in the same namespace. New annotations
(`telepresence.io/downstream-cert-path` and `telepresence.io/downstream-cert-secret`) allow configuration of certificate paths or
secrets for decrypting traffic on specified ports. For mTLS, the `telepresence.io/upstream-cert-` annotation prefix supports
re-encryption of upstream traffic using client-side certificates.
For self-signed certificates, the `telepresence.io/upstream-insecure-skip-verify` annotation bypasses verification, enabling
HTTP-filtered intercepts in development environments. The `--plaintext` option allows unencrypted traffic during intercepts or
wiretaps.
docs: howtos/mtls
- type: feature
title: Add MCP server to Telepresence CLI
body: >-
The Telepresence CLI now includes a lightweight MCP server that can be used to allow local AI agents to execute
some CLI commands, such as connecting to a traffic manager, listing interceptable apps, and creating an intercept.
The server can be enabled using the new `telepresence mcp claude enable` or `telepresence mcp vscode enable` commands.
- type: feature
title: Enhance Resilience of Engagements During Traffic-Manager Redeploys
body: >-
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.
- type: feature
title: Add support for IPv6 and dual-stack when using `telepresence connect --docker`
body: |-
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`
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.
- type: feature
title: RESTful API Service Reintroduced with HTTP Filtering Support
body: >-
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 `--metadata` 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.
docs: reference/restapi
- type: feature
title: More efficient DNS handling in the traffic-manager
body: |-
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.
- type: feature
title: Updated Helm chart to include keywords and the source repository URL.
body: >-
Improves the Helm chart's discoverability on platforms like Artifact Hub and
automatically adds a direct link to the source code for users, providing better context.
- type: change
title: Telepresence client now requires a traffic manager version of at least 2.21.0.
body: >-
The traffic manager is now required to be at least version 2.21.0. Versions earlier than 2.21.0 will no
longer work. The reason for this is that implementing the new reconnect behavior would require too much
conditional code with older traffic-managers, and a lot of functionality wouldn't work anyway.
- type: change
title: Build binaries and docker images that are stripped from dwarf and debug info.
body: >-
The Telepresence binaries and docker images are now built with the `-w -s` flags, which strip the debug
symbols and the DWARF information. This reduces the size of the binaries and docker images by about 50MB.
Debug binaries can be built using `DEBUG=1 make build`.
- version: 2.24.1
date: 2025-09-05
notes:
- type: bugfix
title: Fix invalid filename generated by telepresence gather-logs command
body: >-
The `telepresence gather-logs` command would generate a filename that was invalid on Windows unless the user
specified the filename explicitly using the `--output-file` flag. This was fixed using a more condensed
format for the timestamp in the filename.
docs: https://github.com/telepresenceio/telepresence/issues/3956
- type: bugfix
title: A `telepresence connect --docker` fails kubeconfig points to a port-forwarded localhost
body: >-
Telepresence would fail to connect to a cluster from within a container if the kubeconfig pointed to a
port-forwarded localhost because that localhost is not reachable from within the container. This situation is
now detected so that the address used from within the container has "localhost" replaced with
"host.docker.internal", or an alternative alias configured by the user using the new `docker.hostGateway`
parameter in the client configuration.
- type: bugfix
title: A `telepresence connect --docker` would fail with some k3s configurations
body: >-
Telepresence would fail to connect to a k3s cluster unless the cluster's IP was a loopback address. This is
now changed so that any IP:port combination is accepted as long as a container can be found that defines a
mapping for it.
- type: bugfix
title: Restore default value for agent-state.yaml in the traffic-manager configmap
body: >-
The value was previously an empty string which caused problems when when Argo CD tried to synchronize it.
docs: https://github.com/telepresenceio/telepresence/pull/3953
- version: 2.24.0
date: 2025-08-25
notes:
- type: feature
title: Support for Docker Compose
body: >-
Telepresence now supports integration with Docker Compose. It connects to and interacts with cluster resources
by utilizing `x-tele` 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.
docs: howtos/docker-compose
- type: feature
title: Serve up a web-page with telepresence serve.
body: >-
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.
docs: reference/cli/telepresence_serve
- type: feature
title: Add ability to optionally clean up sidecars that have been idle above a specified duration
body: >-
Added configuration parameter `agent.maxIdleTime` to the Helm Chart, to control how long a sidecar can be idle before it is cleaned up.
The updating of latestEngagementTime is done every 1m in the Remain Call, which is now called every 1min, compared to every 5s in the past.
The agent state (containing latestEngagementTime) is updated in memory, and lazily persisted to the traffic-manager configmap every 2min.
Removal of the sidecar is also done in the Remain Call, if the sidecar has been idle for longer than the configured `agent.maxIdleTime`.
- type: feature
title: Add option to drop client label in prometheus metrics for GDPR compliance
docs: https://github.com/telepresenceio/telepresence/issues/3491
body: >-
The Helm Chart now has a `prometheus.dropClientLabel` option that can be set to true to drop the client label from the prometheus metrics.
This is useful for GDPR compliance, as the client label contains personal data, which can be potentially problematic, i.e allowing the ability to
track the working times of an individual.
- type: feature
title: Prefix metrics with "telepresence_"
docs: https://github.com/telepresenceio/telepresence/issues/3920
body: Avoids metric conflicts and makes these more explicit to improve search in observability stacks.
- type: feature
title: CLI documentation in markdown format
body: >-
The Telepresence CLI is now capable of generating its own documentation in markdown format using the
new `telepresence man-pages` command. The generated documentation is included under the heading "Telepresence
CLI" in the the Telepresence reference documentation.
docs: reference/cli/telepresence
- type: feature
title: Service Port Rerouting
body: >-
The telepresence connect command introduces a new `--reroute-remote <host>:<port>:<new-port>[/{tcp|udp}]` flag,
allowing users to remap service ports. This feature redirects requests sent to `<host>:<new-port>` to
`<host>:<port>` within the Telepresence VIF. The flag can be repeated.
- type: feature
title: Local Port Rerouting
body: >-
The telepresence connect command introduces a new `--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>`. The flag can be repeated.
- type: feature
title: Add information about using Kubernetes auth plugins when using Telepresence CLI in a container
body: >-
Kubernetes, and hence the Telepresence CLI, must have access to auth plugins declared in the kubeconfig. A
section was added to the documentation explaining how to achieve this when using the Telepresence CLI in a
container.
docs: reference/inside-container#kubernetes-auth-plugins
- type: feature
title: Add log directory to the output of `telepresence config view`
body: >-
The `telepresence config view` command now includes the path to the directory where the Telepresence logs are
stored.
- type: change
title: The default port for the mutating webhook is now 8443. It used to be 443
body: >-
Port numbers below 1000 are reserved for privileged processes and are often restricted by firewalls.
Consequently, the default port for the mutating webhook was changed from 443 to 8443. You can override this
default port using the agentInjector.webhook.port value in the Helm Chart. This change is particularly
significant for clusters using Telepresence, where firewall rules limit the admission webhook's access to
worker nodes, such as in an Amazon EKS cluster.
- version: 2.23.6
date: 2025-07-23
notes:
- type: bugfix
title: Public DNS names aren't resolved from local docker application started by Telepresence
body: >-
A container running using `telepresence docker-run` or `telepresence <engage-type> --docker-run` was not able to resolve public
DNS names such as "google.com". The problem is caused by an undocumented behavior in Docker's internal DNS-resolver when the
`--dns` flag is used in conjunction with the teleroute network, where the DNS-server no longer finds public names even thought
another bridge network is connected. The problem was solved by using a fallback resolver in the Telepresence DNS resolver.
- version: 2.23.5
date: 2025-07-20
notes:
- type: bugfix
title: Let docker.Start pass on --interactive to docker start.
body: >-
An `-i` or `--interactive` flag given when the user runs a container with telepresence must be propagated to
`docker start` to attach `stdin`.
- version: 2.23.4
date: 2025-07-18
notes:
- type: bugfix
title: Never truncate meaningful output from a command
body: >-
The new human-friendly output using a progress reporter would sometimes truncate error output. This is no
longer the case. Instead, all output will be wrapped.
- type: bugfix
title: Typo in client mount-policy "RemoteReadonly" should be "RemoteReadOnly"
body: >-
The Helm Chart correctly expects the remote read-only mount policy to be `RemoteReadOnly`, but the client
expected it to be `RemoteReadonly` (without a leading capital letter in the word "only").
- type: bugfix
title: DNS server does not respect semicolons as comments in resolv.conf files
body: >-
Telepresence does not work correctly if `/etc/resolv.conf` contains semicolons, which are valid comments as of
[linux manpage](https://man7.org/linux/man-pages/man5/resolv.conf.5.html).
docs: https://github.com/telepresenceio/telepresence/issues/3908
- type: bugfix
title: Use NXDOMAIN instead SERVFAIL for DNS recursion errors (timeouts)
body: >-
A DNS for a single label name that fails in a minikube - or another type of local cluster - will sometimes
result in a recursive lookup on the host. Without any type of recursion detection, this lookup will timeout
waiting for itself. Previously, this resulted in a `SERVFAIL` from the cluster DNS, which triggered renewed
lookup attempts that never stopped. This is now changed so that the same type of timeouts instead results
in an `NXDOMAIN` error that doesn't trigger renewed attempts.
Also, the recursion check now handles that the cluster's DNS adds suffixes from its search-path.
docs: reference/config#recursioncheck
- version: 2.23.3
date: 2025-07-07
notes:
- type: bugfix
title: Fix tunnel channel reuse in traffic-agent to prevent connection failures
body: >-
Previously, when a tunnel became active, the map maintained by the traffic-agent containing channel values for
agent-to-client tunnels wasn't cleared. This resulted in closed channels remaining in the map. When port
numbers were eventually reused, these stale entries would be discovered and their closed channels would cause
immediate stream termination, leading to data loss.
- type: bugfix
title: The -p flags would have no effect in combination with --docker-run
body: |-
When using `telepresence <engage> --docker-run` with a `-p <port spec>` flag, the Docker driver silently
ignored the port specification. This occurred because the `--network=<teleroute network>` flag disabled both
additional network directives and the default bridge network (which is normally used when no network is
specified). This has been resolved by:
1. Adding the teleroute network after container creation instead of using a flag
2. Replacing the single `docker run` command with a sequence of:
- `docker create`
- Network addition
- `docker start`
- type: bugfix
title: Requests lost when using wiretap
body: >-
Wiretap connection `Close` and `Write` could sometimes be out of sync, so that the `Close` would be executed
before the `Write`, causing a "read/write on closed pipe" error and loss of data.
- version: 2.23.2
date: 2025-06-27
notes:
- type: bugfix
title: Adding an alsoProxy subnet with 32-bit mask no longer works on macOS
body: >-
Routing improvements introduced in 2.23.0 surfaced a problem when using special handling of submets with
32-bit masks. The special handling now causes problems on macOS. The logic is now conditioned to only run
under linux since it's no longer needed on other operating systems.
- type: bugfix
title: The gather-logs command produces no cluster-side logs when connected with --docker
body: >-
The `telepresence gather-logs` command did not include cluster-side logs when connected using `--docker`,
because it tried to store such logs in a temporary directory created by the CLI. The directory was not mounted
in the daemon container. This is now changed so that the temporary directory is created under the users
cache directory, which is guaranteed to be mounted on the container.
- type: bugfix
title: Docker volume mounts failing when connected using both --docker --proxy-via flags
body: >-
The volume mounter would fail when doing a `telepresence connect --docker --proxy-via all=<workload>` followed
by an intercept using `--docker-run`, because the bridge that the daemon created would try to access the
intercepted pod using its proxied IP. Now, the bridge will instead use the pod's real IP.
- version: 2.23.1
date: 2025-06-24
notes:
- type: feature
title: New telepresence helm version command.
body: >-
The new `telepresence helm version` command prints the version of the helm client that is embedded in the
telepresence binary.
- type: bugfix
title: Engagement disconnects after certain amount of time
body: |-
The configuration parameter `connectionTTL`, controlling how long a client could be completely idle before
the traffic-manager or traffic-agent would consider it dead and disconnect (default 24 hours), had no effect.
Instead, an engagement would disconnect after 2 hours (the default gRPC `keepAlive.Time` duration). The
default of 24 hours is now reinstated.
The Helm value `client.connectionTTL` was moved to `grpc.connectionTTL` because it is a server configuration.
The old value will still work, but it is deprecated and will be removed eventually.
docs: https://github.com/telepresenceio/telepresence/issues/3861
- type: bugfix
title: Telepresence breaks if config.yml exists but is empty
body: >-
Telepresence would refuse to connect with a misleading error if the `config.yml` file containing the client's
configuration parameters existed but was empty.
docs: https://github.com/telepresenceio/telepresence/issues/3887
- version: 2.23.0
date: 2025-06-17
notes:
- type: feature
title: New telepresence wiretap command
body: >-
The new `telepresence wiretap` command introduces a read-only form of an `intercept` where the original
container will run unaffected while a copy of the wiretapped traffic is sent to the client.
Similar to an `ingest`, a `wiretap` will always enforce read-only status on all volume mounts, and since that
makes the `wiretap` completely read-only, there's no limit to how many simultaneous wiretaps that can be
served. In fact, a `wiretap` and an `intercept` on the same port can run simultaneously.
- type: feature
title: Add Telepresence Docker Network Plugin "Teleroute"
body: |-
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.
docs: reference/teleroute
- type: feature
title: Control whether the initContainer injection is enabled/disabled
body: >-
The initContainer injection can be optionally disabled by setting the `agent.initContainer.enabled` parameter
to false in the `values.yaml` file of the Helm chart. This feature was added to improve compatibility with
systems like OpenShift where the initContainer injection cannot be used due to inability to give initContainer
NET_ADMIN permissions.
- type: feature
title: Human friendly progress reporting
body: >-
Telepresence now uses a progress reporter that is very similar to the one used by Docker compose. The
implementation is a variation of that reporter's source code, so big thanks to the Docker compose CLI authors
for making it available as OSS.
A new global `--progress <progress>` flag was added. It defaults to "auto" which means that the style is
chosen depending on whether the command runs from a tty type terminal. Other possible values are "plain",
"quiet", and "json". `--progress quiet` is implied when formatted output is chosen using `--output json|yaml`.
- type: feature
title: Add the ability to use a name for the target host, and defer its resolution
body: >-
Knowing the IP of the local service that acts as the handler service for an intercept, replace, or wiretap
is not possible until that service has been started, and telepresence will therefore now accept a name for the
`--address` flag. The name is not resolved by the daemon until a request is made to the engaged container on a
port that is routed to the local service.
- type: feature
title: Add intercept.mountsRoot to the client configuration
body: >-
The new `intercept.mountsRoot` can be set to a directory that will be used as the root for all automatically
generated mount directories. The default is to use the platforms temp directory.
The setting is not used on windows, where the mounts use drive letters.
- type: feature
title: Add docker.addHostGateway to the client configuration.
body: >-
When `docker.addHostGateway` is set to `true`, the `docker run`
that starts the containerized Telepresence daemon will include the flag
`--add-host host.docker.internal:host-gateway`.
The flag is set to `true` by default on linux platforms and `false` on
other platforms.
- type: feature
title: Client configuration to override the Helm download URL
body: >-
The default download URL `oci://ghcr.io/telepresenceio/telepresence-oss` used when installing Helm charts with
versions that differ from the version of the embedded Helm chart can now be overridden using the client config
value `helm.chartURL`.
- type: change
title: Dropped support for Telepresence legacy flags
body: |-
The `telepresence` CLI command will no longer support legacy flags such as:
- `--swap-deployment`
- `--new-deployment`
- `--docker-mount`
- `--method`
A "Legacy Telepresence command used" warning has been printed for several years now, and the mapping for the
`--swap-deployment` was the `intercept` command, which is very confusing today since we now have the `replace`
command.
- type: bugfix
title: Let containerized daemon consistently use the same port for gRPC
body: >-
The port used for the containerized gRPC was randomly selected using the hosts network namespace. This is now
changed so that the port used by the container is preset and configurable and then mapped to a random port
on the host.
The port number can be configured using `grpc.daemonPort` and defaults to `4038`.
- type: bugfix
title: Telepresence fails to start the root daemon on Windows unless current user is the administrator
body:
The telepresence CLI starts a user daemon and a root daemon. The latter is started using administrator
privileges. On a Windows box, this means that the root daemon runs using a different user account (typically
"Administrator") unless the current user can run processes with elevated privileges. The socket used for
communication with the root daemon was assumed to reside in `%USERPROFILE%\AppData\Local\telepresence`
and was therefore not found by the CLI and the user daemon. The location will henceforth always be based on the
`%USERDATA` of the CLI user.
docs: https://github.com/telepresenceio/telepresence/issues/3875
- type: bugfix
title: Telepresence DNS Fallback stripping CNAME information from DNS Records.
body: >-
The fallback DNS server used on Linux systems without a systemd.resolved configuration, would assume that
suffixes belonging to the `search` defined in the `/etc/resolved` had been added by the caller. Since this
search path was assumed to be intended for the local machine only, the suffix was stripped off prior to
sending the name to the cluster for resolution. This made queries fail that relied on the qualified name to
resolve CNAME records. The logic stripping the suffix was therefore removed.
docs: https://github.com/telepresenceio/telepresence/issues/3873
- version: 2.22.6
date: 2025-06-03
notes:
- type: bugfix
title: Regression causing "unexpected slice size" with older traffic-managers.
body: >-
Older traffic-managers have a different way of reporting the service-subnet. The new way, using a
list of subnets reused a proto slice in the GRPC message that was expected to be empty, but older
traffic-managers will pass the IP of the kube-dns here. It cannot be parsed as a list of
subnets. A check that remedies this mismatch was inserted.
- version: 2.22.5
date: 2025-05-29
notes:
- type: bugfix
title: Unable to correctly determine service CIDR with Kubernetes >= 1.33
body: >-
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.
- type: bugfix
title: Helm chart schema type for nodeSelector was incorrect
body: >-
The Helm chart schema for the `nodeSelector` value was incorrect. Kubernetes defines different types for
nodeSelector (inside PodSpec objects) and NodeSelector (inside NodeAffinity, VolumeNodeAffinity and a
bunch of other places). The schema was changed to use the correct type. The name `nodeSelector` is still
used in the Helm chart so this change is backwards compatible.
- type: bugfix
title: Pods with container ports named the same caused intercept to fail
body: >-
Intercept container ports now have numbers appended to them if there are multiple
ports from multiple containers with the same name. This bugfix works around an issue
where Kubernetes allows multiple port definitions in a pod spec to have the same name.
- type: bugfix
title: Don't include k8s-defs.json to chart package
body: >-
The k8s-defs.json was unnecessarily included to the Helm chart package and this increased the Helm release
secret size so much that it could prevent installation of the Helm chart depending on k8s settings. To fix
this k8s-defs.json is not included to the Helm chart anymore.
- version: 2.22.4
date: 2025-04-26
notes:
- type: bugfix
title: Don't require internet access when installing the traffic-manager using Helm
body: >-
A regression occurred with the introduction of Helm validation in version 2.22.0. The schema relied on
external HTTPS links, which inadvertently created a requirement for internet accessibility. To resolve this,
we have embedded these resources within the schema, thus removing the need for an internet connection.
- type: bugfix
title: Client failed connect with "failed to exit idle mode" in the connector.log after being idle
body: >-
The port-forward connections used for connecting the daemon to the traffic-agents were using
an incorrect context, causing them to fail after being idle for some time.
- type: bugfix
title: Fix deadlock in Telepresence daemon
body: >-
A deadlock would sometimes occur in the Telepresence daemon that prevented it from doing a clean
exit during `telepresence quit`.
- type: bugfix
title: Don't log error message when a pod watcher ends due to cancellation
body: >-
Errors printed in the daemon log during normal cancellation of the WatchAgentPods goroutine are
now removed.
- version: 2.22.3
date: 2025-04-08
notes:
- type: change
title: The Windows install script will now install Telepresence to "%ProgramFiles%\telepresence"
body: |-
Telepresence is now installed into "%ProgramFiles%\telepresence" instead of "C:\telepresence".
The directory and the Path entry for `C:\telepresence` are not longer used and should be removed.
- type: bugfix
title: The Windows install script didn't handle upgrades properly
body: |-
The following changes were made:
- The script now requires administrator privileges
- The Path environment is only updated when there's a need for it
docs: https://github.com/telepresenceio/telepresence/issues/3827
- type: bugfix
title: The Telepresence Helm chart could not be used as a dependency in another chart.
body: >-
The JSON schema validation implemented in Telepresence 2.22.0 had a defect: it rejected the `global` object.
This object, a Helm-managed construct, facilitates the propagation of arbitrary configurations from a parent
chart to its dependencies. Consequently, charts intended for dependency use must permit the presence of the
`global` object.
docs: https://github.com/telepresenceio/telepresence/issues/3833
- type: bugfix
title: Recreating namespaces was not possible when using a dynamically namespaced Traffic Manager
body: >-
A shared informer was sometimes reused when namespaces were removed and then later added again, leading
to errors like "handler ... was not added to shared informer because it has stopped already".
docs: https://github.com/telepresenceio/telepresence/issues/3831
- type: bugfix
title: Single label name DNS lookups didn't work unless at least one traffic-agent was installed
body: >-
A problem with incorrect handling of single label names in the traffic-manager's DNS resolver was fixed. The
problem would cause lookups like `curl echo` to fail, even though telepresence was connected to a namespace
containing an "echo" service, unless at least one of the workloads in the connected namespace had a
traffic-agent.
- version: 2.22.2
date: 2025-03-28
notes:
- type: bugfix
title: Panic when using telepresence replace in a IPv6-only cluster
body: |-
A "slice bounds out of range" would occur when the targeted Pod's Traffic Agent requested a local dialer to
be created on the client. This was due to a glitch in the VPN-tunnel implementation that got triggered when
a remote IPv6-address was combined with a local IPv4-address.
docs: https://github.com/telepresenceio/telepresence/issues/3828
- version: 2.22.1
date: 2025-03-27
notes:
- type: bugfix
title: Only restore inactive traffic-agent after a replace.
body: |-
A regression in the 2.20.0 release would cause the traffic-agent to be replaced with a dormant version that
didn't touch any ports when an intercept ended. This terminated other ongoing intercepts on the same pod.
This is now changed so that the traffic-agent remains unaffected for this use-case.
- version: 2.22.0
date: 2025-03-14
notes:
- type: feature
title: New telepresence replace command.
body: |-
The new `telepresence replace` command simplifies and clarifies container replacement.
Previously, the `--replace` flag within the `telepresence intercept` command was used to replace containers.
However, this approach introduced inconsistencies and limitations:
* **Confusion:** Using a flag to modify the core function of a command designed for traffic interception led
to ambiguity.
* **Inaccurate Behavior:** Replacement was not possible when no incoming traffic was intercepted, as the
command's design focused on traffic routing.
To address these issues, the `--replace` flag within `telepresence intercept` has been deprecated. The new
`telepresence replace` command provides a dedicated and consistent method for replacing containers, enhancing
clarity and reliability.
Key differences between `replace` and `intercept`:
1. **Scope:** The `replace` command targets and affects an entire container, impacting all its traffic, while
an `intercept` targets specific services and/or service/container ports.
2. **Port Declarations:** Remote ports specified using the `--port` flag are container ports.
3. **No Default Port:** A `replace` can occur without intercepting any ports.
4. **Container State:** During a `replace`, the original container is no longer active within the cluster.
The deprecated `--replace` flag still works, but is hidden from the `telepresence intercept` command help, and
will print a deprecation warning when used.
- type: feature
title: Add json-schema for the Telepresence Helm Chart
body: >-
Helm can validate a chart using a json-schema using the command `helm lint`, and this schema can be part of
the actual Helm chart. The telepresence-oss Helm chart now includes such a schema, and a new
`telepresence helm lint` command was added so that linting can be performed using the embedded chart.
- type: feature
title: No dormant container present during replace.
body: |-
Telepresence will no longer inject a dormant container during a `telepresence replace` operation. Instead, the
Traffic Agent now directly serves as the replacement container, eliminating the need to forward traffic to the
original application container. This simplification offers several advantages when using the `--replace` flag:
- **Removal of the init-container:** The need for a separate init-container is no longer necessary.
- **Elimination of port renames:** Port renames within the intercepted pod are no longer required.
- type: feature
title: One single invocation of the Telepresence intercept command can now intercept multiple ports.
body: >-
It is now possible to intercept multiple ports with one single invocation of `telepresence intercept` by just
repeating the `--port` flag.
- type: feature
title: Unify how Traffic Manager selects namespaces
body: |-
The definition of what namespaces that a Traffic Manager would manage use was scattered into several Helm
chart values, such as `manager.Rbac.namespaces`, `client.Rbac.namespaces`, and
`agentInjector.webhook.namespaceSelector`. The definition is now unified to the mutual exclusive top-level
Helm chart values `namespaces` and `namespaceSelector`.
The `namespaces` value is just for convenience and a short form of expressing:
```yaml
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: in
values: <namespaces>.
```
docs: install/manager#static-versus-dynamic-namespace-selection
- type: feature
title: Improved control over how remote volumes are mounted using mount policies
body: >-
Mount policies, that affects how the telepresence traffic-agent shares the pod's volumes, and also how the
client will mount them, can now be provided using the Helm chart value `agent.mountPolicies` or as JSON
object in the workload annotation `telepresence.io/mount-policies`. A mount policy is applied to a volume
or to all paths matching a path-prefix (distinguished by checking if first character is a '/'), and can
be one of `Ignore`, `Local`, `Remote`, or `RemoteReadOnly`.
- type: feature
title: List output includes workload kind.
body: >-
The output of the `telepresence list` command will now include the workload kind (deployment, replicaset,
statefulset, or rollout) in all entries.
- type: feature
title: Add ability to override the default securityContext for the Telepresence init-container
body: >-
Users can now use the Helm value `agent.initSecurityContext` to override the default securityContext for the
Telepresence init-container.
- type: change
title: Let download page use direct links to GitHub
body: >-
The download links on the release page now points directly to the assets on the download page, instead of
using being routed from getambassador.io/download/tel2oss/releases.
- type: change
title: Use telepresence.io as annotation prefix instead of telepresence.getambassador.io
body: >-
The workload and pod annotations used by Telepresence will now use the prefix `telepresence.io` instead of
`telepresence.getambassador.io`. The new prefix is consistent with the prefix used by labels, and it also
matches the host name of the documentation site. Annotations using the old name will still work, but warnings
will be logged when they are encountered.
- type: change
title: Make the DNS recursion check configurable and turn it off by default.
body: >-
Very few systems experience a DNS recursion lookup problem. It can only occur when the cluster runs locally
and the cluster's DNS is configured to somehow use DNS server that is started by Telepresence. The check
is therefore now configurable through the client setting `dns.recursionCheck`, and it is `false` by default.
- type: change
title: Trigger the mutating webhook with Kubernetes eviction objects instead of patching workloads.
body: >-
Telepresence will now attempt to evict pods in order to trigger the traffic-agent's injection or removal, and
revert to patching workloads if evictions are prevented by the pod's disruption budget. This causes a slight
change in the traffic-manager RBAC, as the traffic-manager must be able to create "pod/eviction" objects.
- type: change
title: The telepresence-agents configmap is no longer used.
body: >-
The traffic-agent configuration was moved into a pod-annotation. This avoids sync problems between the
telepresence-agents (which is no no longer present) and the pods.
- type: change
title: Drop deprecated current-cluster-id command.
body: >-
The clusterID was deprecated some time ago, and replaced by the ID of the namespace where the traffic-manager
is installed.
- type: bugfix
title: Make telepresence connect --docker work with Rancher Desktop
body: >-
Rancher Desktop will start a K3s control-plane and typically expose the