create services
A Service's spec.externalIPs is programmed into kube-proxy DNAT rules, so traffic to that address reaches the attacker's pod from any namespace (CVE-2020-8554).
The API server does not validate the address and accepts one already claimed by another Service, leaving the outcome to the kube-proxy dataplane.
RBAC cannot restrict a single field, so the control is the DenyServiceExternalIPs admission plugin.
Note:
CVE-2020-8554 is a design issue: users who can create or modify Services with spec.externalIPs can intercept traffic to those IPs.
Mitigate with admission policy and strict RBAC; do not rely on a Kubernetes patch level alone.
- API Group
- (core)
- Scope
- namespaced
- Audit Level
- RequestResponse
Escalation Paths
Create or patch a Service and set spec.externalIPs to an address used by another pod, a node, or an off-cluster host.
kube-proxy programs DNAT for that address on every node, sending traffic for it to the Service's endpoints.
NetworkPolicy does not contain this, since policy selects on pod addresses rather than on a Service's externalIPs.
The API server accepts an address already claimed as another Service's ClusterIP.
Which rule wins is decided by the dataplane, not by validation.
Behaviour differs by kube-proxy mode.
iptables favours the first matching rule, while IPVS and eBPF dataplanes resolve collisions on their own terms, so confirm the mode before relying on precedence.
Additional rights needed:
Note:
spec.externalIPs is deprecated as of 1.36 and warns on write, but it stays fully functional.
kube-proxy still programs the DNAT identically.
Deprecated is not mitigated (CVE-2020-8554).
Restricting it requires an admission webhook that validates externalIPs.