Kubernetes v1.36 Deprecates Service ExternalIPs Due to Security Vulnerabilities

by

Kubernetes v1.36 introduces the formal deprecation of the Service.spec.externalIPs field. This change addresses long-standing security concerns and the project's dissatisfaction with the feature's “insecure by default” state.

Security Risks and CVE-2020-8554

The externalIPs field was an early mechanism to provide load-balancer-like functionality for non-cloud clusters. However, the API assumes that every user in the cluster is fully trusted. This assumption creates a security risk: if an attacker can create a ClusterIP service and set the spec.externalIPs field, they can intercept traffic destined for that IP address. This vulnerability is documented as CVE-2020-8554.

Timeline for Removal

The Kubernetes community has recommended disabling this field since version 1.21, but blocking it by default was deemed too large a breaking change at the time. The new timeline is:

  • v1.36 (Current): The field is deprecated. Warnings are emitted when the field is used.
  • v1.40 (Earliest): Support for .spec.externalIPs will be disabled in kube-proxy. Users can opt back in if needed.
  • v1.43 (Earliest): Support will be disabled completely; no opt-back-in option will remain.

Alternatives and Migration

Administrators currently using externalIPs should migrate to one of the following alternatives:

1. Manual LoadBalancer Services

You can switch to a type: LoadBalancer service and manually assign an IP to the .status.loadBalancer.ingress field. This isolates the IP from the .spec field, making it harder for regular users to modify, though it still carries some risk if permissions are misconfigured.

# Create service without a load balancer IP
kubectl apply -f loadbalancer-service.yaml

# Manually patch the status to add the IP
kubectl patch service my-example-service --subresource=status --type=merge -p '{"status":{"loadBalancer":{"ingress":[{"ip":"192.0.2.4"}]}}}'

2. Non-Cloud Load Balancer Controllers

Tools like MetalLB provide a robust solution for non-cloud environments. Administrators can define IP pools, ensuring that IP addresses are managed centrally and preventing conflicts.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: production
  namespace: metallb-system
spec:
  addresses:
  - 192.0.2.0/24
  autoAssign: true
  avoidBuggyIPs: false

3. Gateway API

This is the recommended modern approach. Gateway resources allow administrators to attach IP addresses to gateways, with RBAC controls ensuring only privileged users can manage them.

Immediate Action

To prepare for the deprecation, administrators are advised to enable the DenyServiceExternalIPs admission controller. This ensures that any future use of the externalIPs field is blocked immediately.