The vulnerability stems from a missing authorization check in the NodeRestriction admission controller, which failed to validate ResourceClaims during pod creation by a node. This allowed a compromised node to create a mirror pod that could access unauthorized dynamic resources. The analysis of the patch reveals a defense-in-depth approach to mitigation, with fixes applied at three distinct stages of pod processing.
-
Admission Control (admitPodCreate): The primary vulnerability is addressed in the admitPodCreate function of the NodeRestriction admission plugin. This is the point where the authorization decision should have been made. The patch adds the crucial missing check to forbid a node from creating pods that reference ResourceClaims.
-
API Validation (validatePodResourceClaim): As a second layer of security, the generic API validation logic is hardened. The validatePodResourceClaim function now explicitly blocks static pods (mirror pods) from being created with ResourceClaims, preventing such invalid objects from entering the system.
-
Kubelet Configuration (tryDecodeSinglePod): The third layer of defense is at the kubelet level. When the kubelet reads a static pod manifest from a file, the tryDecodeSinglePod function now rejects it if it contains ResourceClaims. This ensures that even if a malicious manifest is placed on the node's filesystem, the kubelet will refuse to process it.
An attacker exploiting this vulnerability would trigger a code path involving these three functions. The absence of checks in these functions in their vulnerable state would allow the malicious pod to be created. Therefore, these functions are key runtime indicators for detecting exploitation attempts.