Egress Gateway: Control Your Mesh's Outbound Traffic

Why it exists

In a zero-trust network, you control service-to-service traffic. But what about traffic leaving the mesh to external APIs? Without a central control point, any service can call any external endpoint, creating security holes and making auditing impossible. An Egress Gateway solves this by funneling all outbound traffic through a single, manageable exit point.

The mental model

Think of an Egress Gateway as the single, secured loading dock for a large factory (your service mesh). Instead of every workshop shipping its own packages out any available window, all outbound shipments are routed through the loading dock. There, security can inspect them, log them, and ensure they're going only to approved destinations.

How it works

You deploy a dedicated Envoy proxy as a gateway at the edge of your mesh. You then use Istio resources to direct outbound traffic from your services to this gateway. A ServiceEntry defines an external service, making it known to the mesh. A Gateway resource configures the egress gateway pod itself (ports, protocols). Finally, a VirtualService binds to the ServiceEntry and routes the traffic through the configured Gateway. This allows the gateway to apply policies like timeouts, retries, and TLS origination on behalf of the internal services.

When to use it

Use an Egress Gateway when you need to enforce consistent policy on traffic leaving the mesh. This is crucial for security compliance, like limiting egress to an allow-list of external domains. It's also useful for monitoring all outbound traffic in one place or for originating mTLS connections to external services when your internal applications can't handle it themselves.

When not to use it

For simple setups where outbound traffic control isn't a security or operational requirement, an egress gateway adds complexity and an extra network hop. If your cluster's default network policies (like Kubernetes NetworkPolicy) are sufficient for your egress control needs, you might not need an Istio Egress Gateway.

One canonical example

A common use case is forcing all traffic to an external API, like api.partner.com, to go through the egress gateway. You would create a ServiceEntry for api.partner.com. Then, you'd configure a VirtualService to route requests for this host through the egress gateway. This ensures that even if a pod is compromised, it can't exfiltrate data to arbitrary endpoints, only to the explicitly allowed external services routed through the gateway.