Skip to content

Kubernetes v1.36: Deprecation and removal of Service ExternalIPs

Kubernetes 1.36 formally deprecates the .spec.externalIPs field for Service resources, with plans to remove the implementation entirely in a future minor release.

Advisory Summary

This field, originally designed to provide cloud-load-balancer-like functionality for non-cloud clusters, has carried unresolved security vulnerabilities since its introduction. The core issue is that the API assumes all cluster users are fully trusted. In multi-tenant or less-trusted environments, this assumption enables documented security exploits detailed in CVE-2020-8554. SIG Network has recommended disabling this feature since Kubernetes 1.21 and provided the DenyServiceExternalIPs admission controller to enforce this restriction, but the feature has remained enabled by default. The deprecation marks a shift from the project's previous stance that blocking the functionality by default would create too severe a breaking change. With better alternatives now available for load balancer functionality in non-cloud environments, Kubernetes maintainers are moving to eliminate this insecure-by-default feature entirely.

Affected Components and Versions

The deprecation affects Kubernetes 1.36 and all future versions. Any cluster currently using the .spec.externalIPs field in Service definitions will be impacted. This includes both cloud and non-cloud deployments, though the feature was primarily intended for bare-metal and on-premises clusters lacking native load balancer integration.

The specific component being deprecated is the .spec.externalIPs field in the Service API. When this field is populated, kube-proxy configures the node networking to respond to requests on those specified IP addresses. In future releases, kube-proxy will stop implementing this behavior, and the Kubernetes conformance criteria will be updated to explicitly prohibit conforming implementations from supporting this functionality.

Clusters that have already enabled the DenyServiceExternalIPs admission controller are not affected operationally, as they have already blocked this feature. Clusters running with default configurations or those that explicitly use external IPs for service exposure will need to migrate to alternative approaches before the feature is removed entirely.

Why It Matters

The security implications of .spec.externalIPs create real risk in any environment where cluster access is not restricted to a small, fully trusted group of users. CVE-2020-8554 documents how malicious or compromised users can exploit this feature to intercept traffic intended for legitimate services or to claim IP addresses they should not control. In multi-tenant clusters or environments with namespace-level delegation, this represents a privilege escalation vector.

Beyond the security concern, clusters that depend on this feature face a forced migration in upcoming Kubernetes releases. The timeline for complete removal has not been specified, but the formal deprecation in 1.36 signals that removal could occur in subsequent minor versions following standard Kubernetes deprecation policies. Operators need to identify usage now and plan migration paths before the functionality disappears.

The shift also reflects the maturation of better alternatives. Projects like MetalLB, Cilium's load balancing capabilities, and other CNI-integrated solutions now provide more robust and secure methods for exposing services in non-cloud environments. These alternatives offer proper access controls, better integration with network policies, and more sophisticated traffic management without the inherent trust assumptions of .spec.externalIPs.

  1. Audit current Service configurations to identify any use of the .spec.externalIPs field across all namespaces. Run this command to find affected Services:

    kubectl get services --all-namespaces -o json | jq -r '.items[] | select(.spec.externalIPs != null) | "\(.metadata.namespace)/\(.metadata.name)"'

  2. Enable the DenyServiceExternalIPs admission controller immediately on clusters where .spec.externalIPs is not in active use. Add DenyServiceExternalIPs to the --enable-admission-plugins flag in kube-apiserver configuration. Verify activation with:

    kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get --show-kind --ignore-not-found -n default

  3. Evaluate replacement solutions for clusters currently relying on external IPs. For bare-metal clusters, assess MetalLB in Layer 2 or BGP mode. For clusters with advanced CNI plugins, investigate native load balancer integrations provided by your CNI. Document the IP addresses currently in use and their associated services.

  4. Test migration in non-production environments by deploying your chosen alternative and migrating one service at a time. Verify that traffic routing works correctly and that IP addresses are properly announced or assigned. Confirm that existing clients can reach services at their expected addresses.

  5. Create a migration timeline that completes before upgrading to the Kubernetes version that removes .spec.externalIPs support entirely. Track the Kubernetes release notes for announcements about removal timing. Budget for potential network architecture changes if your current setup cannot be directly translated to alternative solutions.

  6. Update any infrastructure-as-code templates, Helm charts, or deployment manifests that include .spec.externalIPs specifications. Search your configuration repositories for this field and remove it after migration is complete.