EndpointSlice validation omitted restrictions on node-local addresses

Two APIs can describe related networking state while enforcing different security rules. CVE-2021-25737 is an example in Kubernetes. The API server already rejected localhost and link-local IP addresses in Endpoints, but EndpointSlices did not receive the same validation. An authorized writer could use that gap to redirect Pod traffic toward private networks on a node.

The 18 May advisory identifies kube-apiserver as the affected component. It rates the issue Low and specifies high privileges in its CVSS assessment. This is not a claim that any unauthenticated network client can redirect a cluster's traffic. The vulnerability matters where a user has the API permissions needed to supply the relevant endpoint configuration.

I value Kubernetes' extensible API model, but related resources need consistent validation when they can influence the same behavior. An operator who understands the restrictions on Endpoints should not have to discover that the EndpointSlice representation omitted them.

An address can be valid syntax and an invalid destination

Endpoint data influences where Service traffic goes. The reported gap concerns the meaning of a destination address, not whether a string has the syntax of an IP address. A localhost address is syntactically valid, but using it as a Service endpoint can cause traffic to reach a destination associated with the node itself.

Link-local addresses present a related problem. The advisory identifies the IPv4 ranges 127.0.0.0/8 and 169.254.0.0/16 as the destinations to reject in a temporary admission policy. These are specific restrictions on endpoint values. They do not amount to a general ban on every private network address.

That distinction is important for understanding the threat. The advisory says traffic can be redirected into private networks on a node. It does not claim that all nonpublic endpoint addresses are invalid, nor that Kubernetes should prohibit all Services that point outside a Pod address range.

The missing check creates an inconsistency between API representations. Restricting one representation is insufficient when another accepted representation can produce the same forbidden destination. The security property needs to hold at every supported input that can describe that destination.

The fixed validation is shared

The versioned validation code in 1.21.1 shows the repair in context. For an IPv4 endpoint address, validation checks that the value is an IPv4 address and calls ValidateNonSpecialIP. The IPv6 branch performs its corresponding address-family check and invokes the same non-special-address validation.

These checks live inside the routine that validates an EndpointSlice's endpoints. The create validation entry point calls the common EndpointSlice validator. The update entry point also validates the new object through that routine before checking the immutability of its address type.

That placement matters because restricting only creation would leave an update path to consider. Here the common validation operates on the new endpoint data for both operations. The address-family and special-address checks remain separate, which makes the two requirements visible in the implementation.

The FQDN branch uses domain-name validation instead. The patch should therefore be read as IP-address validation for the relevant address types. It does not introduce a general mechanism for deciding whether every possible name or external destination is trustworthy.

The API server is the appropriate enforcement point for this fix because it evaluates the object being admitted. Repairing only a particular client would leave other authorized API callers able to submit the problematic data. Client-side checks can be useful, but they cannot establish this server-side restriction.

Affected and fixed versions

The public tracking issue lists the affected versions alongside the disclosure. Kubernetes 1.21.0 is affected. The affected 1.20 releases run through 1.20.6, and the affected 1.19 releases run through 1.19.10.

The advisory also includes versions 1.16.0 through 1.18.18. It qualifies that range by noting that EndpointSlices were not enabled by default in 1.16 through 1.18. That qualification affects exposure, so merely identifying a version in the older range does not establish that its cluster was using the vulnerable mechanism.

The fixed versions are 1.21.1, 1.20.7, 1.19.11, and 1.18.19. These are the specific patch releases identified in the disclosure. The correction applies to kube-apiserver validation, which keeps the remediation tied to the component that accepts the objects.

Version information needs that level of precision in a security post. Saying that EndpointSlices became stable recently does not explain which earlier clusters could be affected. Conversely, describing every older cluster as exposed would discard the advisory's explicit feature-enablement qualification.

Mitigation and inspection cover different needs

For clusters that cannot immediately upgrade kube-apiserver, the advisory recommends a validating admission webhook that rejects EndpointSlices containing addresses in the two named IPv4 ranges. An existing admission policy system, such as OPA Gatekeeper, can enforce the restriction.

This mitigation addresses future admission decisions. It belongs at the point where an object is accepted, and its relevant input is the set of endpoint addresses. The advisory's recommendation does not require changing application code or teaching every Service client how to detect a forbidden destination.

Inspection has a different purpose. The advisory recommends listing EndpointSlices and checking their endpoint addresses for the same two ranges. This examines the cluster's recorded state for evidence of the reported configuration. It is not equivalent to establishing that no traffic has ever followed such a destination.

The distinction between prevention and evidence is useful here. An admission restriction can reject new problematic input, while inspection can identify recorded endpoint data that warrants investigation. Neither action should be described as a complete historical account of network activity.

My judgement is that this fix illustrates a maintenance obligation of API evolution. When a newer resource describes related routing information, its validation must preserve the restrictions on the older representation. Kubernetes closes this particular gap by applying special-IP validation to EndpointSlice addresses inside the API server's shared create and update validation path.