Kubernetes & Cloud Native · 25.07.2026, 15:29 UTC
Routing egress traffic to wildcard destinations
| Schweregrad | info |
|---|---|
| Kategorie | Kubernetes & Cloud Native |
| Quelle | Istio ↗ |
| Veröffentlicht | 25.07.2026 UTC |
Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.
If you are using Istio to handle application-originated traffic to destinations outside of the mesh, you’re probably familiar with the concept of egress gateways. Egress gateways can be used to monitor and forward traffic from mesh-internal applications to locations outside of the mesh. This is a useful feature if your system is operating in a restricted environment and you want to control what can be reached on the public internet from your mesh. The use-case of configuring an egress gateway to handle arbitrary wildcard domains had been included in the official Istio docs up until version 1.13, but was subsequently removed because the documented solution was not officially supported or recommended and was subject to breakage in future versions of Istio. Nevertheless, the old solution was still usable with Istio versions before 1.20. Istio 1.20, however, dropped some Envoy functionality that was required for the approach to work. This post attempts to describe how we resolved the issue and filled the gap with a similar approach using Istio version-independent components and Envoy features, but without the need for a separate Nginx SNI proxy. Our approach allows users of the old solution to seamlessly migrate configurations before their systems face the breaking changes in Istio 1.20. Problem to solve The currently documented egress gateway use-cases rely on the fact that the target of the traffic (the hostname) is statically configured in a VirtualService, telling Envoy in the egress gateway pod where to TCP proxy the matching outbound connections. You can use multiple, …