Kubernetes CVE-2023-2728: Understanding the NodeRestriction Admission Bypass

NodeRestriction and Its Security Model

The NodeRestriction admission plugin is a fundamental security control in Kubernetes that limits what a kubelet can modify via the API server. The intended model is that a node can only modify objects it owns: its own Node object and the pods scheduled to it. It cannot modify pods on other nodes, cannot modify cluster-scoped resources, and critically, cannot modify pod labels that are used for pod security policy or namespace selector enforcement — because doing so would allow a compromised node to escape its assigned security boundaries.

The Bypass: CVE-2023-2728

CVE-2023-2728 demonstrated that a node could bypass the NodeRestriction label restrictions by modifying pods that were in a terminating state. Kubernetes tracks pod phase separately from the API-level deletion marker, and the NodeRestriction admission plugin's label validation logic did not correctly apply restrictions to pods in the terminating phase. A compromised kubelet could modify security-relevant labels on terminating pods, potentially affecting policy enforcement decisions made while the pod was winding down.

The vulnerability was fixed in Kubernetes 1.24.14, 1.25.9, 1.26.4, and 1.27.1. Clusters running older minor versions without the backport are still affected.

Impact Assessment

The practical impact depends heavily on how pod labels are used in your cluster's security model:

• Clusters using PodSecurity admission (the replacement for PodSecurityPolicy) are the primary risk surface, since the PSA controller evaluates labels at admission time and pod metadata.
• Clusters using label selectors in NetworkPolicy rules could see a compromised node route traffic through pods that bypass intended network segmentation.
• Service mesh admission — for example, Istio sidecar injection controlled by namespace or pod labels — could be bypassed to prevent security proxy injection.

Hardening Beyond the Patch

Patching to a fixed version is necessary but not sufficient. A hardened Kubernetes cluster should layer additional controls that reduce the blast radius of any admission control bypass:

• Enable audit logging for all API server requests and alert on NodeRestriction-adjacent operations from kubelet service accounts.
• Use OPA Gatekeeper or Kyverno policies to provide defence-in-depth label protection independent of built-in admission plugins.
• Restrict kubelet RBAC to the minimum required permissions using the Node authorizer and avoid binding cluster-admin to node service accounts.
• Regularly validate that admission plugin configuration matches intended policy using automated configuration auditing.

How OSSeva Helps

OSSeva's Operate service includes Kubernetes configuration auditing that identifies admission plugin gaps, validates NodeRestriction is enabled and correctly configured, and surfaces CVEs affecting your specific minor version. When advisories like CVE-2023-2728 are published, affected clusters appear in your dashboard within hours of the advisory publication.

Conclusion

NodeRestriction bypasses represent a class of Kubernetes vulnerability that is particularly dangerous because they subvert a foundational security assumption. Beyond patching, the correct response is to treat admission control as one layer of a defence-in-depth strategy rather than a single gate, and to audit that strategy continuously rather than at deployment time.