Piotr Jabłoński: Istio's security policy breach | CONFidence

### Overview In this presentation, Piotr Jabłoński, a Solutions Architect at Isovalent (Cisco), explores cross-level isolation challenges in cloud-native environments, focusing on a vulnerability demonstrated in Istio Ambient Mesh. While service meshes provide L4 mutual TLS (mTLS) and access control policies, Jabłoński shows how architectural decisions—specifically placing shared proxies on nodes and exposing the control plane—can lead to severe security policy breaches. The talk also broadens its scope to cover serverless security pitfalls (particularly AWS Lambda defaults) and highlights the necessity of multi-layered, lateral isolation across organizations, networks, runtimes, and identities.

### Key Topics - **Istio Ambient Mesh vs. Traditional Sidecars**: Ambient mesh replaces individual sidecar containers with a shared per-node proxy called `ztunnel` alongside `istiod` and the Istio CNI node agent. While this avoids sidecar resource overhead and shared container secret exposure, it exposes the node proxy directly to tenant pods. - **Control Plane Exposure and Policy Breach**: Standard unprivileged pods can reach `ztunnel` and `istiod` IP addresses. By executing a basic denial-of-service (DoS) flood during scheduled RBAC policy updates, the proxy enforcement fails open, granting cluster-wide access to unauthorized pods. - **Serverless Isolation Realities**: Contrary to common assumptions regarding AWS Lambda's shared responsibility model, Lambda functions by default do not run within a customer VPC, can initiate outbound internet connections, can trigger reverse shells, and can expose code or runtime files if compromised. - **Defense-in-Depth & Distributed Security**: True isolation requires addressing foundations: identity management (RBAC/labels), anti-spoofing, CNI-level filtering, sandbox testing, VPC attachment for serverless workloads, and placing distributed security controls close to applications.

### Technical Details - **Ambient Mesh Attack Mechanism**: In Istio version 1.20, `ztunnel` synchronizes and updates RBAC authorization policies every 30 minutes. Jabłoński configured an authorization policy restricting access to specific service accounts (e.g., `sleep` accessing `bookinfo`/`productpage`). From an unprivileged pod with no elevated permissions or host PID access, he ran flood commands using `hping` (`hping --flood`) combining TCP SYN packets, UDP traffic, and ICMP floods against the `ztunnel` control-plane IP. Stressed by the flood during the 30-minute policy update window, the proxy suffered an enforcement bypass, allowing previously rejected `curl` connections across the entire cluster to succeed. - **Observed Istio Behaviors**: Jabłoński noted that older versions failed to enforce updated policies on pre-existing TCP connections, and highlighted that Ambient Mesh does not inspect or filter UDP/ICMP traffic by design. In extreme failures where communication to `istiod` or `ztunnel` completely terminates, Istio Ambient behaves as "fail-closed" (denying all communication), contrasting with some other systems that "fail-continue" using cached kernel policies. - **Remediation**: The TCP SYN flood bypass during updates was reported to Google/the Istio project and patched in Istio version 1.22. However, the speaker emphasized that network reachability to the control plane and uninspected UDP/ICMP traffic remain architectural surfaces that must be mitigated with CNI policies and OS hardening.

### Takeaways - **Protect the Control Plane**: Do not rely exclusively on L7 or L4 service mesh abstractions. Isolate control plane components (`istiod`, `ztunnel`) from standard application workloads using network policies, Kubernetes CNIs with anti-spoofing, and protocol filtering. - **Re-evaluate Serverless Defaults**: Serverless functions require intentional network configuration. Always place sensitive cloud functions inside a VPC or VNet to enforce firewall rules, monitor outbound flows, and manage DNS traffic. - **Establish Job Zero Hygiene**: Consistent labeling, separation of duties, and robust identity planning are prerequisites for effective automated enforcement in CI/CD and infrastructure-as-code pipelines.