Webinar: Live Hack: Hack My Mis-Configured Kubernetes, sponsored by Snyk

### Overview In this webinar sponsored by Snyk, Or Kamara, a Senior Development Team Lead at Snyk, demonstrates how common Kubernetes misconfigurations can be exploited by attackers and how developers can remediate them. The session frames modern development security across application source code, third-party dependencies, Docker images, and infrastructure as code, referencing real-world multi-step cloud breaches such as the Capital One incident. Kamara walks through practical demonstrations highlighting three key configuration areas: privileged pods, root containers, and resource limitations.

### Key Topics - **Developer Responsibility & Attack Surface**: Managing security across the software supply chain, including source code, open-source packages, base OS image dependencies, Terraform, and Kubernetes deployment YAML manifests. - **Privileged Pods**: The dangers of granting host-level permissions to containers, enabling container escapes and unauthorized access to host file systems and neighboring workloads. - **Root Containers & Capabilities**: Risks of default root container execution, alongside mitigations using granular Linux capabilities (`drop: ["ALL"]`) and the `runAsNonRoot` directive in Kubernetes security contexts. - **Resource Limitations & DoS Attacks**: The impact of unbounded CPU and memory defaults, demonstrating how one compromised application can exhaust node memory and disrupt neighboring innocent services. - **Infrastructure as Code Scanning**: Catching and understanding configuration flaws early in the development pipeline using CLI and Git integration tools such as Snyk Infrastructure as Code.

### Technical Details - **Privileged Pod Exploitation and Fix**: - A vulnerable web application with a Remote Code Execution (RCE) vulnerability allowed an attacker to upload a PHP script executing system commands. - Because the pod ran with `privileged: true`, the attacker used `curl` to trigger the PHP web shell, executed `mkdir /tmp/host`, and mounted the host filesystem (`mount /dev/... /tmp/host`). - Because both the vulnerable application and a sensitive payment service ran on the same node sharing local Docker storage, the attacker searched the mounted host filesystem (`cat ... card.json`) to read sensitive credit card records stored by the payment app. - *Remediation*: Setting `privileged: false` in the pod's `securityContext` prevented mounting host filesystems, returning `Operation not permitted` / `Permission denied`. - **Root Container Hardening**: - Many base images (such as PHP) run as `root` by default, allowing attackers to perform reconnaissance using network scanners like Nmap and pinging other internal services. - *Linux Capabilities Solution*: Setting `capabilities: drop: ["ALL"]` removes dangerous capabilities such as `CAP_NET_RAW`, disabling Nmap's raw packet transmission and failing ping attempts. - *Non-Root Enforcement*: Setting `runAsNonRoot: true` causes Kubernetes to block pod execution at startup if the container attempts to run as root, throwing a `CreateContainerConfigError`. - **Resource Quotas Demonstration**: - By default, Kubernetes pods run with unbounded resource limits. CPU throttling degrades performance, while uncompressible memory limits lead to termination. - Kamara demonstrated a Denial of Service (DoS) attack where a vulnerable pod allocated memory spikes (100MB+), quickly exhausting available node memory and impacting adjacent workloads. - *Remediation*: Defining explicit memory `limits` constrained container allocations; subsequent over-allocation attempts failed, shielding neighboring applications on the shared node.

### Takeaways - Kubernetes security configuration is an essential, inseparable component of application development rather than an isolated operational concern. - Default settings in Kubernetes are permissive; developers must explicitly enforce non-privileged execution, drop unneeded Linux capabilities, enforce non-root users, and set memory and CPU requests and limits. - Organizations should adopt automated Infrastructure as Code (IaC) security scanning within CI/CD and local developer environments to detect and remediate misconfigurations before production deployment.