Istio’s Envoy sidecar intercepts most outbound traffic via iptables but excludes specific UIDs, protocols, and lacks as a security boundary.

Istio uses istio-init to modify pod iptables, redirecting traffic to the Envoy sidecar. This capture mechanism is protocol-specific and has intentional exclusions.

What Envoy Captures

• TCP traffic (HTTP, gRPC, MySQL, etc.) on intercepted ports (default: all except loopback)
• Traffic not sourced from UID 1337 (Envoy’s own UID to prevent loops)
• Outbound traffic destined for known mesh services (if outboundTrafficPolicy: REGISTRY_ONLY)

Key Exceptions

1. UDP and ICMP: Not captured by default (no iptables rules for these protocols)
2. Envoy-generated traffic: UID 1337 is explicitly excluded to avoid recursion
3. Explicitly excluded ports: Defined via sidecar.egress[].ports in IstioService entries
4. outboundTrafficPolicy: ALLOW_ANY: Allows traffic to unknown destinations without Envoy interception

Actionable Workflow to Verify Capture

1. Check iptables in the pod namespace:

   ns=$(podman exec -it <pod-name> nsenter --target 1 --mount -- iptables -L -n -v | grep 'ESTABLISHED'  
   

2. Inspect Istio outboundTrafficPolicy:

   istioctl x envoy-config bootstrap -n <namespace> --type sidecar --instance <pod-ip>:15006 | grep outboundTrafficPolicy  
   

3. Test with allowed/block scenarios:
   • Use curl http://unknown-service.com (ALLOW_ANY permits, REGISTRY_ONLY blocks)
   • Use ping or nc for UDP to confirm non-interception

Concrete Policy Example

To enforce capture for known services only:

apiVersion: networking.istio.io/v1alpha3  
kind: PeerAuthentication  
metadata:  
  name: strict-egress  
spec:  
  selector:  
    matchLabels:  
      app: my-app  
  mtls:  
    mode: STRICT  
  outboundTrafficPolicy:  
    mode: REGISTRY_ONLY  

Tooling for Diagnosis

• iptables inspection:

  podman exec -it <pod-name> sh -c "iptables -L -n -v | grep -E 'tcp|udp'"  
  

• Envoy access logs:

  istioctl x envoy-config access-log -n <namespace> --instance <pod-ip>:15006  
  

• Network sniffing:

  podman exec -it <pod-name> tcpdump -i eth0 -n  
  

Tradeoffs and Caveats

• No security boundary: A compromised pod can modify its own iptables or run as UID 1337 to bypass Envoy.
• Protocol limitations: UDP-based services (DNS, Kafka) require explicit configuration or alternative egress controls.
• Performance overhead: Intercepting all TCP traffic adds latency; selective port capture reduces this but requires maintenance.

Troubleshooting Common Issues

• Traffic bypassing Envoy:
  • Check if source UID is 1337 (Envoy itself)
  • Verify traffic isn’t UDP/ICMP
  • Confirm no port exclusions in IstioService definitions
• Unexpected blocks with REGISTRY_ONLY:
  • Ensure all required services are in the mesh registry
  • Use istioctl analyze to detect misconfigurations
• Envoy recursion loops:
  • Confirm outboundTrafficPolicy isn’t misconfigured
  • Check for custom iptables rules in the pod

For actual security enforcement, combine Istio with Kubernetes NetworkPolicies and dedicated egress gateways. The sidecar is a traffic management tool, not a firewall.

Source thread: Istio: does envoy capture all outbound traffic?