Discloses a man-in-the-middle vulnerability in which LoadBalancer Services or External IPs are used to hijack traffic from other Pods in multi-tenant clusters by creating or updating Service status fields.
Impact scope
All Kubernetes versions are affected. This vulnerability stems from a Kubernetes design flaw. The fixing plan is tracked in issue 97110.
Your cluster is vulnerable if it is multi-tenant or runs applications deployed by untrusted users. To detect attacks, check the API server audit log for Service status field patch events. See Work with cluster auditing.
Attack vectors
In a multi-tenant cluster, attackers can intercept traffic forwarded to a target Service:
- Create a ClusterIP Service and set the externalIP field in spec to a target IP address. Traffic sent to that IP is then intercepted and forwarded to this Service.
- Set the spec.loadBalancerIP field and patch the status.loadBalancer.ingress.ip field of a LoadBalancer Service. Traffic sent to the original IP is then intercepted and forwarded to the modified address.
Prevention and mitigation
The Kubernetes community has not released an official fix yet, and remediation may require substantial changes to the core model, so a formal patch is still expected to take considerable time. To mitigate this vulnerability, prioritize the following measures:
-
Limit external IP address usage:
- Use admission webhooks to validate and authorize external IP addresses. The Kubernetes-provided externalip-webhook offers a reference implementation.
- Use Open Policy Agent (OPA) Gatekeeper to restrict external IP ranges. See gatekeeper for setup, and externalip for sample ConstraintTemplate and Constraint templates.
-
Limit LoadBalancer Service IP usage:
- Minimize permissions for patching the Service status field.
- Use admission webhooks or OPA Gatekeeper to restrict external IPs for LoadBalancer Services.