K8s – Pod to Node Escape Techniques

In this article we are exploring the breakout of a pod, to gain access to a node. This is performed by attackers to elevate their privileges in a Kubernetes environment and furthermore allows access to other pods running on the node and the nodes file system. This does not only compromise the containers running on the machine, but can also lead to lateral movement between several namespaces depending on the pods scheduled under the compromised node.

Attack Scenarios

This attack can be performed in different circumstances, while it is bound to different requirements.

Depending on the attack scenario and the Kubernetes environment there can be some limitations to the pod to node escape. If for example the Pod Security Admission controller is configured and set to the profile and the mode is set to , you cannot spawn another pod within the cluster (or namespace) with the privileged flag enabled.

Furthermore, other security solutions might play into the attack you are performing and alerting could go off if a container is spawned with sensitive capabilities, host namespace ‘forwarding’ or privileged.

Demo

In this article we assume the compromise of a pod or service account with the permissions create . We also add other permissions such as get and list for simplicity. Mandatory however is only the create permissions for pods.

We created a lab environment that consists of three pods, the pod we assumed to have control over compormised-pod , an alpine pod and a nginx pod. The compormised-pod and the nginx pod are located on the same node minikube-m03 , while the alpine pod is located on the minikube-m02 node. This will become relevant in the bonus section. For the sake of this demo no Pod Security Admission control was or policies were enabled.

Performing the attack

Once we obtained command line access on a container within a Kubernetes Cluster, we want to check the service account permissions if a service account was attached to the pod.

kubectl auth can-i — -list

As we can see here, using the kubectl binary we are listing the service account permissions given to the compromised-pod . This service account has the desired create verb for the resource pods . We can now leverage this (assuming no other security boundaries are in place), to escape from the pod to the node.

We first need to create a podSpec for our ‘escape’ container. This can be done in different ways, such as giving sensitive capabilities to the container, exposing kernel namespaces to it, mounting the hosts volume or simply running the container in a privileged mode. Depending on security solutions in place, different variations might apply here. It might not always be possible to gain full control over the node.

In our case we are creating a privileged container that mounts the hosts volume to our container. Furthermore, we define the nodeName to be minikube-m03. If we remember from the lab setup, the nginx pod and the compromised-pod are running on this node.

We also need to make sure that we gain command line access to the newly created container. For this we need to know the IP of an instance we control and achieve the connection by including a reverse shell in the command field of the podSpec.