Hello Kubernetes Community,
A security issue was discovered with Kubernetes affecting multitenant clusters. If a potential attacker can already create or edit services and pods, then they may be able to intercept traffic from other pods (or nodes) in the cluster.
This issue has been rated medium severity (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L), and assigned CVE-2020-8554.
An attacker that is able to create a ClusterIP service and set the spec.externalIPs field can intercept traffic to that IP. An attacker that is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
This issue is a design flaw that cannot be mitigated without user-facing changes. With this public announcement, we can begin conversations about a long-term fix.
All Kubernetes versions are affected. Multi-tenant clusters that grant tenants the ability to create and update services and pods are most vulnerable.
There is no patch for this issue, and it can currently only be mitigated by restricting access to the 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
To restrict the use of external IPs we are providing an admission webhook container: k8s.gcr.io/multitenancy/externalip-webhook:v1.0.0. The source code and deployment instructions are published at https://github.com/kubernetes-sigs/externalip-webhook.
Alternatively, external IPs can be restricted using OPA Gatekeeper. A sample ConstraintTemplate and Constraint can be found here: https://github.com/open-policy-agent/gatekeeper-library/tree/master/library/general/externalip.
No mitigations are provided for LoadBalancer IPs since we do not recommend granting users patch service/status permission. If LoadBalancer IP restrictions are required, the approach for the external IP mitigations can be copied.
ExternalIP services are not widely used, so we recommend manually auditing any external IP usage. Users should not patch service status, so audit events for patch service status requests authenticated to a user may be suspicious.
If you find evidence that this vulnerability has been exploited, please contact secu...@kubernetes.io
See the GitHub issue for more updates: https://github.com/kubernetes/kubernetes/issues/97076
This vulnerability was reported by Etienne Champetier of Anevia.
Thank You,
Tim Allclair on behalf of the Kubernetes Product Security Committee