With the release of Kubernetes 1.36, the .spec.externalIPs field on Services is officially deprecated. This long-criticized feature, initially meant to mimic cloud load balancer behavior in non-cloud clusters, poses unresolved security vulnerabilities. Kubernetes now encourages migration to more secure load-balancer mechanisms that provide stronger policy controls and IP allocation governance.
- Deprecated .spec.externalIPs to close critical security gaps
- Shift to LoadBalancer-type Services with IP management controllers
- Future Kubernetes versions to drop support and update conformance
Infrastructure signal
Kubernetes 1.36 formally deprecates the use of the .spec.externalIPs field in Service definitions due to persistent security vulnerabilities, most notably those detailed in CVE-2020-8554. This field, once intended to simulate cloud load-balancer behavior in clusters without cloud provider integrations, assumes all cluster users are fully trusted, an assumption that no longer holds universally true.
Going forward, kube-proxy and the Kubernetes conformance requirements will phase out handling of this field, signaling a shift in how clusters expose services externally. Instead, the project encourages leveraging managed load-balancer controllers such as MetalLB to provide controlled IP address assignments and avoid IP conflicts or unauthorized accesses. This change aims to improve overall cluster security posture and IP management sanity.
Developer impact
Developers currently relying on .spec.externalIPs for service exposure must migrate their configurations to use type: LoadBalancer Services combined with approved load-balancer controllers. Unlike the previous approach, load balancer IP addresses are assigned and managed on the Service's status field, restrictable by RBAC, thus reducing the potential for abusive IP takeover by unprivileged users.
This shift requires a two-step service creation process: first creating the Service without an external IP, then assigning an IP through the controller. For environments without cloud providers, implementing tools like MetalLB allows developers to request specific IP addresses from an administrator-controlled pool, improving both operational security and consistency of external access.
What teams should watch
Teams maintaining legacy cluster configurations or multi-tenant setups must audit usage of .spec.externalIPs immediately and assess migration strategies. Enabling the DenyServiceExternalIPs admission controller is strongly recommended to proactively prevent new uses. Security teams should monitor upcoming Kubernetes releases for the execution of the full removal of externalIPs support, as cluster software and tooling will need updating accordingly.
Platform and network teams should evaluate alternatives such as MetalLB or other third-party load balancer controllers that support IP pool management and RBAC integration. These tools provide the necessary governance mechanisms to safely expose services externally without risking IP hijacking or collision, aligning cluster external traffic management with current security best practices.