A Kubernetes vulnerability has been identified that could allow an attacker to intercept traffic from other pods in multi-tenant Kubernetes clusters.
The vulnerability, discovered by Etienne Champetier of Anevia, can be exploited remotely in a man-in-the-middle attack by an individual with basic tenant permissions, without any user involvement required.
If an attacker has permissions to create and update services and pods, they could potentially intercept traffic from other pods or nodes in the cluster. When a service is created with an arbitrary external IP, all traffic to that external IP from within the cluster will be routed to that service. If an attacker can create a service with an external IP, they will be able to intercept traffic to any target IP.
The flaw, tracked as CVE-2020-8554, affects all Kubernetes versions and requires little skill to exploit; however, the potential for exploitation is limited as only a small number of Kubernetes deployments are likely to be affected, as External IP services do not tend to be used often in multi-tenant clusters. It is also not a good best practice to grant tenant users patch service/status permissions for LoadBalancer IPs.
The vulnerability has been assigned a medium severity rating, and while the Kubernetes development team has yet to provide a patch to correct the flaw, there are mitigating steps that can be taken to reduce the potential for exploitation. Until a security update is released, this is only possible by restricting access to vulnerable features.
“Because an in-tree fix would require a breaking change, we will open a conversation about a longer-term fix or built-in mitigation after the embargo is lifted,” said Tim Allclair, in a security advisory issued on behalf of the Kubernetes Product Security Committee.
External IP usage can be restricted by using an admission webhook container or by restricting External IPs using Open Policy Agent Gatekeeper. There is no fix for LoadBalancer IPs, since the recommended configuration is not vulnerable. Users should also manually audit External IP usage to identify attacks attempting to exploit the vulnerability. “Users should not patch service status, so audit events for patch service status requests authenticated to a user may be suspicious,” said Allclair.
