Skip to content

Hack my Talk! But it's deployed on Kubernetes

Benjamin Koltermann

CloudTROOPERS IT Security Conference43 minOpen on YouTube ↗

Security researchers examine technical aspects of Hack my Talk! But it's deployed on Kubernetes.

Summary

### Overview In this talk, Benjamin Koltermann explores the inherent security architecture and logic of vanilla Kubernetes rather than focusing on software bugs or third-party products. Demonstrating attacks directly against the Kubernetes infrastructure hosting his own presentation slides, he illustrates how standard, built-in platform capabilities can be abused by attackers who obtain initial access to a cluster, container, or worker node.

### Key Topics - **Kubernetes Architecture and Security Fundamentals:** Overview of core objects (nodes, namespaces, deployments, services, ingress) and control-plane components (kube-apiserver, etcd, kubelet, and container runtimes). Hardening requirements include role-based access control (RBAC), disabling unauthenticated anonymous access on the kubelet, and strictly avoiding privileged containers. - **Container Breakouts:** Demonstration of escaping a container via elevated host privileges (`hostPID: true` and running privileged pods), using `nsenter` to enter the host's mount and PID namespaces to attain root on the underlying node. - **Data Exfiltration via Validating Admission Webhooks:** Abusing Kubernetes admission controller configurations to intercept and exfiltrate sensitive cluster resources (such as secrets) across all namespaces to an external command-and-control (C2) server. - **Deployment Hijacking via Node Labels:** Exploiting access to a node and kubelet credentials (`kubelet.conf`) to manipulate node labels, tricking Kubernetes schedulers into placing workloads intended for other nodes or teams onto attacker-controlled nodes. - **Stealthy Persistence and Auto-Scaling Malware via Pause Containers:** Replacing the container runtime's default pause/sandbox image with a trojanized version to achieve unmonitored, auto-scaling code execution inside every pod. - **Platform Threat Modeling:** Introduction of a MITRE ATT&CK-style threat matrix mapped specifically to Kubernetes attacks to bridge application security and platform security.

### Technical Details - **Admission Webhook Secret Interception:** By applying a `ValidatingWebhookConfiguration` targeting `create` and `update` operations on the `secrets` resource across any API group or version, Kubernetes forwards the full API request payloads to an external webhook endpoint (an nginx server). The speaker demonstrates extracting and base64-decoding the cleartext secret data from the incoming request logs. - **Node Relabeling and Node Restriction:** With root access on a worker node, an attacker can extract credentials from `/etc/kubernetes/kubelet.conf` to interact with the API server. By executing `kubectl label nodes <node> app=slides --overwrite`, the attacker matches the `nodeSelector` of other deployments, causing scaled or restarted pods to schedule on their compromised node. To mitigate this vector, the speaker demonstrates the `NodeRestriction` admission plugin, which enforces that labels formatted as `node-restriction.kubernetes.io/*` cannot be modified by kubelets. - **Weaponizing Pause Containers:** The pause container (`pause.c`) runs in every Kubernetes pod to maintain Linux network namespaces and reap zombie processes. In container runtimes like containerd, the sandbox image path configured in `/etc/containerd/config.toml` can be modified to point to a custom image. Once containerd is restarted, every newly scheduled pod automatically instantiates the attacker's custom pause container before starting application containers. Because this mechanism operates directly at the runtime level below the Kubernetes API, it evades commercial in-cluster scanners and persists across container restarts.

### Takeaways - Securing Kubernetes requires defense across both the application layer and the underlying platform layer, as compromise of either affects the other. - Administrators must actively harden default configurations: disable anonymous kubelet access, enforce RBAC, disallow privileged containers, and employ admission controllers like `NodeRestriction` to safeguard critical metadata and scheduling controls. - Container runtimes and low-level sandbox components (such as pause containers) represent powerful persistence vectors that bypass standard Kubernetes API visibility.

Related talks