This week, the Kubernetes Product Security Committee disclosed a new security issue (CVE-2020-8554) that affects every version of Kubernetes. It is medium severity and no patch is available. Kubernetes administrators are advised to (1) limit certain cluster permissions as well as (2) restrict and manually audit external IP usage within clusters. It is also recommended that multi-tenant cluster scenarios be reconsidered where possible and appropriate.
Vulnerability Summary
CVE-2020-8554 is a man-in-the-middle (MITM) vulnerability that exists in every version of Kubernetes with the most significant impact on multitenant clusters. It can be exploited by users with basic permissions such as creating or editing services and pods in a Kubernetes cluster. A user who has these permissions may be able to intercept traffic from other pods in the cluster. This is most easily done by creating a service, which allows a user to specify a cluster IP address and also expose a service using an external IP address. Traffic to that external IP address from the cluster will be routed to that service, enabling the user to intercept it. This can also be accomplished by patching the status of a load balancer service. It is worth noting that the vulnerability itself does not grant unauthorized users the ability to create Kubernetes services.
Kubernetes Versions Impacted
All versions of Kubernetes (v1.0-1.20) are impacted, making the scope of this vulnerability significant. However, as subsequently described, the circumstances under which clusters are most vulnerable are primarily those that are running multi-tenant.
Analysis
The impact of this vulnerability is concerning because the reality is that many Kubernetes clusters today are multi-tenant, with many users sharing access to create services, and this issue stems from a design flaw or rather, a lack of accounting for this scenario at the time features were designed. We have previously observed Kubernetes vulnerabilities associated with misconfigured RBAC settings but those have typically required granting users elevated privileges. In this case, the vulnerability arises from basic user permissions meaning attacks can be carried out with low complexity. The Kubernetes community will need to determine how best to address this longer-term, and it seems it will require backwards-incompatible design changes.
Recommendations
Given the absence of a patch for this vulnerability, the only approach that Kubernetes administrators can take is to apply appropriate mitigations. The attack vector that utilizes the load balancer service IP can be mitigated by restricting the patch/service status permission, though this is not a commonly granted permission considering that it involves a privileged operation.
Administrators should look to restrict the use of external IPs with one of the following methods:
- OPA Gatekeeper: sample constraint template
- Admission controller: sample one: externalip-webhook
- Policy enforcement mechanisms specific to various Kubernetes platforms (e.g., Anthos Policy Controller)
Since the use of external IPs and patch service status requests are both uncommon, it is also recommended that events for either of these activities be manually audited as well. Finally, where possible, clusters that do not require multiple user access should reconsider multi-tenant configurations in the meantime.