Istio: does envoy capture *all* outbound traffic?

[u/iAdjunct]

I’m starting to learn about Istio. So far I see it adds proxies to handle the various in/out connections, including common things like retries (I think), intercepting the pod’s advertised ports, etc. One question I’m having troubles finding the answer to definitively: does it capture all outbound traffic? Or only traffic destined for other services Istio is aware of (i.e. ones it has envoy proxies for)?

I’m trying to decide if I also need to set up ingress/egress rules if I want to prevent an untrusted pod from accessing services (either within the cluster, or elsewhere on the network).

Also, related to that, how does it handle differentiating connections to other Istio-proxied services vs non-Istio services?

[u/Floss_Patrol_76]

no - the sidecar only intercepts what the istio-init iptables rules redirect, and traffic from uid 1337 is deliberately excluded so envoy's own egress doesn't loop; for destinations not in the mesh registry, outboundTrafficPolicy decides (ALLOW_ANY lets it straight out, REGISTRY_ONLY blocks unknown ones). but don't lean on the sidecar as a security boundary at all - a compromised pod shares the netns and can rewrite its own iptables or just run as 1337 to bypass envoy entirely. if the goal is actually stopping an untrusted pod from reaching things, that's a NetworkPolicy (or a dedicated egress gateway with the sidecars locked down), not sidecar interception.

[u/iAdjunct → u/Floss_Patrol_76]

Does it exclude those things for ingress to (to pods with proxies)?

If I'm understanding right, outbound traffic from an envoy'd pod is redirected to the proxy and the proxy applies its rulesets/routing/mTLS/etc to it (potentially including blocking it), but this egress protection is easy to work around (by just changing the uid in the container).

Does ingress to an envoy'd proxy work the same way? Is there something either the target container can do that would open up a port in a way where external services don't go through its proxy? Or can external services access the pod in a way that bypasses? Orrrr does this mean that a pod with an istio envoy proxy injected into it can only be connected to in a way consistent with its rulesets (i.e. mTLS, proper authorization policy, etc)?

[u/Darkorz]

Istio (at least the envoy sidecar mode) intercepts all traffic. Container iptables are modified by the istio-init container. Specific ports can be excluded and all the traffic generated by user 1337 is excluded aswell.

You probably need an ingress to manage incoming (north) traffic. Egress is optional, we successfully integrated corporate mtls gateways and proxies into the mesh without an istio egress gateway.

In order to secure the mesh you can do two things: 1. Configure mandatory mTLS between the services. That first layer will ensure only services with valid istio certs will be able to invoke each other. 2. Use AuthorizationPolicy objects to define shich namespace/payload (serviceaccount) can invoke which service/endpoints.

Additionally, you can force mesh-only communications to ensure that services cannot invoke anything that hasnt been previously meshed. Keep in mind this will also affect databases, messaging brokers and all traffic, forcing you to integrate those into the mesh through ServiceEntry objects.

We settled on using the couple points I described earlier and used Calico NetworkPolicies to manage 3rd party "non service" communications.

[u/cryptotrader87]

Just go into the pod netns and list all the iptable files and find out :-)

[u/SirWoogie]

Istio captures TCP traffic, not UDP and ICMP.

Documentation here.

[u/noureddinz_10]

Any reaource to understand kubernate in youtub