Kubernetes v1.36 Phases Out Service ExternalIPs: What You Need to Know

Introduction

The Kubernetes project has long recognized the security risks associated with the .spec.externalIPs field for Services. As of version 1.36, this feature is formally deprecated, marking a significant step toward a more secure default configuration. In this article, we will explore why this change was made, what it means for your clusters, and how to transition to safer alternatives.

What Are Service ExternalIPs?

The .spec.externalIPs field was an early attempt to provide cloud load balancer functionality for non-cloud Kubernetes clusters. Administrators could specify additional IP addresses—beyond the cluster’s internal network—that the Service would answer on. This allowed traffic from outside the cluster to reach the Service without a full load balancer.

However, this design came with a dangerous assumption: that every user in the cluster is fully trusted. In any environment where that assumption fails, externalIPs opens the door to multiple security exploits, as documented in CVE-2020-8554.

Deprecation in Kubernetes 1.36

Since Kubernetes 1.21, the community has recommended disabling .spec.externalIPs. An admission controller—DenyServiceExternalIPs—was added to make that easier, but it was not enabled by default. The SIG Network originally hesitated to block the feature by default, fearing it would be too large a breaking change.

Now, the security concerns remain and have only grown more pressing. With better alternatives available for non-cloud clusters, the project has decided to formally deprecate the field in Kubernetes 1.36. A future minor release is expected to remove the implementation from kube-proxy and update conformance criteria to exclude this feature. This means that if you rely on externalIPs, you need to plan your migration now.

Terminology Clarification

The term "external IP" has multiple meanings in Kubernetes. To avoid confusion:

• Service.spec.externalIPs – the deprecated field for adding IP addresses a Service responds on.
• Node.status.addresses (ExternalIP) – a type of IP address assigned to nodes.
• kubectl EXTERNAL-IP – a column showing the load balancer IP for type: LoadBalancer Services.

This deprecation only affects the first item. If you are not setting externalIPs in any Service, the change does not impact your cluster. However, as a precaution, consider enabling the DenyServiceExternalIPs admission controller to block future misuse.

Alternatives to ExternalIPs

If you currently use .spec.externalIPs, here are several safer, more modern alternatives. The choice depends on your infrastructure and requirements.

Manually-Managed LoadBalancer Services

The simplest (but least recommended) replacement is to switch from externalIPs to a type: LoadBalancer Service and manually assign an IP address. While functionally similar, the load balancer IP becomes part of the Service's .status, not its .spec. In clusters with RBAC enabled, ordinary users cannot edit the .status field, which reduces the attack surface.

MetalLB (Bare-Metal Load Balancer)

For on-premises clusters, MetalLB is a popular load balancer implementation that works without cloud provider integrations. It can assign IP addresses from a pool you define, offering true load balancer semantics. MetalLB is a drop-in replacement that provides the same functionality as externalIPs but with proper security boundaries and integration with Kubernetes objects.

NodePort Services

If you only need to expose a Service on a specific port on each node, type: NodePort is a straightforward option. The cluster automatically assigns a high port (30000–32767) on every node, and you can configure an external firewall or proxy to forward traffic to that port. NodePort is not a load balancer but is often sufficient for development or internal services.

Ingress Controllers

For layer-7 routing, an Ingress controller (such as NGINX Ingress, Traefik, or HAProxy) can expose HTTP/HTTPS services without needing externalIPs. The Ingress resource defines rules for routing traffic, and the controller implements them, typically using a LoadBalancer Service or NodePort for external access. Ingress is the preferred way to expose web applications.

External DNS with Load Balancer Controllers

Combine a load balancer controller (e.g., MetalLB or cloud-provider) with ExternalDNS to automatically manage DNS records. This gives you a fully automated, secure setup comparable to cloud load balancers, without relying on externalIPs.

Migration Steps

1. Identify all Services using .spec.externalIPs – Run kubectl get services --all-namespaces -o json and filter for those with externalIPs set.
2. Evaluate alternatives – Choose the best replacement based on your use case (see above).
3. Deploy the new configuration – For example, install MetalLB and create new LoadBalancer Services, or switch to Ingress.
4. Update DNS and clients – Point any external DNS records or client connections to the new IPs or hostnames.
5. Enable the admission controller – Activate DenyServiceExternalIPs to prevent future use in your cluster.
6. Test and remove old Services – After confirming traffic flows correctly, delete the old Services that used externalIPs.

Conclusion

The deprecation of .spec.externalIPs in Kubernetes 1.36 is a necessary step toward a more secure cluster by default. While it imposes a migration burden, the available alternatives—MetalLB, NodePort, Ingress, and others—provide robust, secure solutions for exposing services in non-cloud environments. Start planning your migration today to stay ahead of the upcoming removal and ensure your cluster remains both functional and secure.