Services that list addresses in spec.externalIPs

An address field Kubernetes never controlled

externalIPs makes the cluster route traffic that arrives for arbitrary addresses, on the Service’s port, into the Service. The Service documentation notes that Kubernetes does not manage allocation of these addresses; that is left to the cluster administrator. It also marks the field deprecated since v1.36 and tells users to migrate to an external load balancer controller or a Gateway API implementation.

The security problem is older. The Kubernetes security advisory for CVE-2020-8554 explains that an attacker who can create a ClusterIP Service and set spec.externalIPs can intercept traffic to that IP, from other pods or nodes. It is a design flaw with no patch, affecting all Kubernetes versions, and multi-tenant clusters where tenants can create Services are the most exposed.

Auditing Services for externalIPs

kubectl get services -A -o json | jq -r '
  .items[]
  | select(((.spec.externalIPs // []) | length) > 0)
  | "\(.metadata.namespace)/\(.metadata.name) externalIPs=\(.spec.externalIPs | join(","))"'

The advisory itself recommends manually auditing any external IP usage, since the feature is not widely used.

Any listed address triggers it

ZopNight reads the externalIPs list recorded for each Service and fires when it contains at least one entry. An absent or empty list is compliant. No other property of the Service, such as its type or namespace, changes the outcome.

What it does not look at

The advisory describes a second route to the same interception, patching a LoadBalancer Service’s status, which needs a privileged permission and is not something this check can see. Ordinary LoadBalancer Services are reported separately by Service type LoadBalancer.

Interception risk, no saving

There is no savings figure for this medium-severity security finding. The risk is traffic meant for one destination being silently redirected to a workload an attacker controls.

Retiring externalIPs

1. Find out what depends on each listed address and how that address reaches the nodes.
2. Expose the workload through a LoadBalancer Service, an Ingress or a Gateway instead.
3. Remove the field: kubectl patch service <name> -n <namespace> --type=json -p='[{"op":"remove","path":"/spec/externalIPs"}]'.
4. Block new usage. Where you control API server admission plugins, the DenyServiceExternalIPs admission controller rejects new externalIPs while leaving existing ones alone; otherwise, use a policy engine such as OPA Gatekeeper, which the advisory names.