create pods/binding

Binding an unscheduled Pod to any chosen Node bypasses the scheduler's taint checks entirely, since the kubelet never re-validates taints.

Binding is a separate subresource most policy engines never inspect, unlike spec.nodeName at pod create, so it also evades admission policy.

This matches the real system:kube-scheduler role, which holds create on pods/binding but not on pods itself.

A compromised scheduler inherits this and can redirect any pending Pod, not just its own.

T0 with following verbs:

A chosen pod placed on a control plane node, past the taint meant to exclude it

pods/binding assigns a node directly, and the taint that keeps workloads off the control plane is enforced by the scheduler rather than at admission.

The binding decides where; a pod spec with hostPath or privileged decides what it can do once there.

Escalation Paths

Compromise a scheduler component, built-in or custom, whose ServiceAccount holds create on pods/binding but not pods itself, matching the real system:kube-scheduler role
RBAC cannot filter by a Pod's schedulerName field, so any Pod already Pending in the cluster is fair game, not only ones addressed to that scheduler
Create a Binding object for a target Pod naming the desired Node directly, skipping the scheduler's own logic entirely
The kubelet does not re-check taints at admission, so the Pod runs even on a NoSchedule-tainted node with no matching toleration
Admission policy engines typically register their webhook on pods CREATE/UPDATE only.
Binding is a different subresource they never inspect, so node-placement policies never see it
Targeting a control plane node places a workload past the taint meant to keep it off.
Combined with a privileged/hostPath Pod spec, this reaches node compromise

Additional rights needed:

none