I'm learning how Istio sidecars handle traffic between pods and external services. I understand that the sidecar uses iptables rules to intercept connections, apply routing, retries, mTLS, and authorization, but I'm unclear about the scope of that interception. Does it capture every outbound connection, or only traffic destined for services registered in the mesh? How does it distinguish between meshed and non-meshed destinations? I'm also trying to determine whether Istio egress rules are enough to stop an untrusted pod from reaching services inside or outside the cluster, and whether inbound connections to a sidecar-injected pod can bypass the proxy.
3 Answers
For service-to-service security, combine strict mTLS with AuthorizationPolicy. mTLS verifies that the caller has a valid mesh identity, while authorization rules determine which service account, namespace, or request attributes may access a particular service or endpoint. You can also use REGISTRY_ONLY if the goal is to prevent mesh workloads from contacting undeclared destinations, but databases, brokers, and other external dependencies then need ServiceEntry definitions. NetworkPolicy remains useful for enforcing lower-level connectivity, especially for non-mesh services.
Inbound traffic to an injected workload is normally redirected to the sidecar before reaching the application, so Envoy can enforce TLS and authorization policies. However, injection and interception are not equivalent to an unbreakable sandbox. Excluded ports, unusual network paths, host-level access, misconfigured iptables, or a compromised workload can undermine those assumptions. Treat Istio policies as part of a layered design and use NetworkPolicy or other infrastructure controls when the requirement is to prevent an untrusted pod from reaching specific destinations.
In sidecar mode, Istio generally redirects the pod’s TCP traffic to Envoy using iptables, regardless of whether the destination is another meshed service. There are important exceptions: explicitly excluded ports can bypass interception, Envoy’s own traffic is excluded to prevent a loop, and traffic such as UDP or ICMP is not handled the same way. For destinations outside the mesh, the outbound traffic policy matters: ALLOW_ANY permits unknown destinations, while REGISTRY_ONLY blocks destinations that have not been defined with a ServiceEntry. This is traffic control, not a strong security boundary—someone who controls the pod may be able to alter iptables, use an excluded identity, or otherwise bypass the sidecar. Use Kubernetes NetworkPolicy for basic reachability restrictions, and consider an egress gateway when centralized outbound control is required.
That makes sense for outbound traffic. I’m still wondering whether inbound connections to an injected pod are guaranteed to pass through Envoy, or whether the application can expose a port or be reached through some path that bypasses the proxy.