Escalating Attack and Defense on Cloud based Kubernetes

The talk examines how Kubernetes clusters running on AWS hand cloud credentials to individual workloads, and where those mechanisms break down. The starting problem is that by default every container on a node shares the node's IAM role, so anything running there can reach every service that role allows. The speaker traces three generations of workload identity tools, including kube2iam, kiam and IAM Roles for Service Accounts.

In the middle section, the demos assume an attacker has escaped a container or landed on a node through an overprivileged pod. Against kube2iam, the attacker enumerates the roles used across the cluster and assumes them directly from the node. With kiam, the server never checks whether a requesting agent actually hosts the pod IP it claims, so stolen agent credentials allow impersonation of any pod. The speaker reports a zero-day in this design and notes that the project has moved into maintenance mode. The service account approach fares better, because short-lived tokens are mounted as volumes, although a node's filesystem still exposes the tokens of pods running on it.

The practical takeaway is to treat the node as a trust boundary. Sensitive workloads can be separated onto dedicated node groups, pod creation and privileged or host-path volumes should be restricted, and the metadata endpoint should be blocked where it is not needed. Identity brokers should also be checked to confirm they verify which pod is asking for credentials. Defaults alone do not provide that separation.