In IPVS mode, host services become available on ClusterIPs #72236
Description
What happened:
In IPVS mode, if a service on the host is listening on 0.0.0.0:<some port>, pods on the local host (or incoming traffic from other hosts if routing allows it) to any ClusterIP on <some port> reaches the host service.
For example, a pod can access its host's ssh service at something like 10.96.0.1:22
What you expected to happen:
ClusterIPs should reject or drop traffic to unexpected ports (as is the behaviour in iptables mode).
How to reproduce it (as minimally and precisely as possible):
- Turn on IPVS mode for kube-proxy
- Configure ssh to listen on 0.0.0.0 (the default in most installations)
- Exec into a pod and ssh to, say
10.96.0.1:22, should reach the host.
Anything else we need to know?:
This unexpected behaviour has some security impact; it's an extra, unexpected, way for packets to reach the host. In addition, it's very hard for a NetworkPolicy provider to secure this path (such as Calico) to secure this path because IPVS captures traffic that, to the kernel's policy engines, looks like it's going to be terminated at the host. For example, in iptables, there's no way to tell the difference between traffic that is about to be terminated by IPVS and traffic that's going to go to a local service.
Related Calico issue; user was trying to block the traffic with Calico policy but was unable to (because Calico has to whitelist all potential IPVS traffic): projectcalico/calico#2279
Environment:
- Kubernetes version (use
kubectl version): 1.12 - Cloud provider or hardware configuration:
- OS (e.g. from /etc/os-release):
- Kernel (e.g.
uname -a): - Install tools:
- Others:
/kind bug