Getting ahead of the schedule: manipulating the Kubernetes scheduler to perform lateral movement in a cluster — Paul Viossat
Date : 06 June 2024 à 14:30 — 30 min.
In Black Hat 22, Yuval Avrahami & Shaul Ben Hai (https://www.blackhat.com/us-22/briefings/schedule/#kubernetes-privilege-escalation-container-escape--cluster-admin-26344) explored ways of compromising clusters using dangerous RBAC permissions in a Kubernetes cluster. They tried to answer a difficult question: on which conditions a node compromission implies a full cluster compromission ? Their answer can be summarized as: it depends on the permissions of service accounts bound to the compromised node.
However, when attacking a cluster, it's not always possible to get lucky and compromise a node with interesting service accounts. As a defender, we also don't want the security of our cluster to depend on the random distribution of pods on nodes.
But is it really random? Actually, no. The positioning of pods in the cluster is governed by an essential component of kubernetes clusters: the scheduler.
In this article, we continue Yuval Avrahami & Shaul Ben Hai's work by introducing a methodical means of analyzing the pods (and consequently the service accounts) accessible from a node: the domains of feasibility.
We will then see how, in a defense-in-depth approach, we can restrict the pods accessible to a node that may have been compromised thanks to workload isolation.
Finally, we'll look at attack techniques that take advantage of a lack or classic flaws in the implementation of isolation in a Kubernetes cluster. These techniques will show that it is possible to compromise a cluster, still on some conditions, without a single service account accessible from a node.
This will answer the question posed above: on which conditions does a node compromise imply a full cluster compromise? It depends on the permissions of service accounts bound to the compromised node and on the pod's isolation in the cluster.