Container Security and Kubernetes Escape: Defense Guide
Containers provide process isolation, not security isolation. A container running as root with host path mounts and privileged capabilities can escape to the underlying host in multiple ways. Kubernetes amplifies this: a compromised pod with excessive RBAC permissions can escalate to cluster-admin, access secrets across all namespaces, and pivot to cloud provider credentials. Understanding the attack techniques is the prerequisite to building defenses that actually work.
Container Escape Techniques
Container escapes exploit misconfigurations in how containers are deployed rather than vulnerabilities in the container runtime itself (though runtime CVEs like runc escapes do occur). Common escape techniques:
Privileged container escape
Containers running with --privileged or specific Linux capabilities (CAP_SYS_ADMIN, CAP_NET_ADMIN) have near-host-level access. A privileged container can mount the host filesystem, load kernel modules, and access host namespaces. Defense: never run privileged containers in production; enforce this with Pod Security Admission.
Host path mount abuse
Containers with host path volumes mounted (hostPath: /etc, /var/run/docker.sock, /) can read and write to the host filesystem directly. Docker socket access in particular allows the attacker to create a privileged container via the Docker API. Defense: prohibit sensitive host path mounts via admission control.
Kernel exploit via container
Vulnerabilities in the Linux kernel can be exploited from within a container to escape to the host. The Dirty Pipe (CVE-2022-0847) and recent runc escapes followed this pattern. Defense: keep kernel versions current, use seccomp profiles to restrict syscalls available to containers.
Service account token abuse
Every Kubernetes pod is automatically mounted with a service account token unless explicitly disabled. If the service account has RBAC permissions, an attacker who compromises the pod can use the token to interact with the Kubernetes API. Defense: automountServiceAccountToken: false for pods that do not need it; RBAC least privilege for service accounts.
Kubernetes Privilege Escalation Paths
After compromising a pod, attackers use Kubernetes RBAC to escalate privileges toward cluster-admin. Common escalation paths:
Secret access escalation
A pod with permission to list or get secrets across namespaces can retrieve service account tokens and other credentials. Use these to authenticate as a more privileged service account.
Pod creation escalation
Permission to create pods allows creation of a privileged pod with host path mounts, effectively granting host access. Any service account with pods/create and pods/exec can escalate to host access this way.
Role binding creation
Permission to create ClusterRoleBindings allows granting cluster-admin to a controlled service account. This is the highest-priority RBAC permission to restrict.
Node access via DaemonSet
Permission to create DaemonSets allows deploying a privileged container to every node in the cluster, achieving cluster-wide host access.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Image Security: Shift Left
Vulnerable container images are the foundation of most container security incidents. Image security must start in the CI/CD pipeline, not in production:
Image scanning in CI/CD
Scan images at build time using Trivy, Grype, or Snyk Container. Fail builds that introduce new critical vulnerabilities. This is faster feedback than scanning in production.
Minimal base images
Use distroless images (Google's distroless, Chainguard Wolfi) that contain only the application and its runtime dependencies, no shell, no package manager, no debugging tools. Smaller attack surface, fewer vulnerabilities.
Image signing and verification
Sign container images with Sigstore/cosign and verify signatures at admission time using Kyverno or OPA Gatekeeper. Prevents running unsigned or tampered images in production clusters.
Registry hygiene
Pull images only from trusted registries. Configure Kubernetes to require images from approved registries using admission control. Regularly scan registry contents and remove images that are no longer used.
Pod Security and Admission Control
Kubernetes Pod Security Admission (PSA) is the built-in policy enforcement mechanism that replaced the deprecated PodSecurityPolicy. Configure PSA at the namespace level with three profiles:
Privileged
No restrictions. Only for system namespaces (kube-system) that require elevated privileges. Never use for application namespaces.
Baseline
Prevents the most dangerous misconfigurations (privileged containers, host namespaces, dangerous capabilities). A good starting point for most application namespaces.
Restricted
The most secure profile: requires non-root users, read-only root filesystem, drops all capabilities, requires seccomp profile. Use for any namespace running untrusted workloads or handling sensitive data.
Runtime Detection
Static controls (RBAC, PSA, image scanning) prevent known bad configurations. Runtime detection catches attacker behavior after a container is compromised. Deploy a container runtime security tool (Falco, Aqua, Sysdig Secure, Prisma Cloud Runtime) that monitors syscall activity within containers and alerts on:
Shell spawned in container
Legitimate containers should not spawn interactive shells in production. Any exec or spawn of /bin/bash, /bin/sh, or /bin/zsh in a running production container is suspicious.
Unexpected network connections
Alert on containers initiating outbound connections to IP addresses outside the application's expected communication patterns. Container workloads should have defined egress requirements.
Sensitive file access
Access to /etc/passwd, /etc/shadow, service account token paths (/var/run/secrets/), or credential files within a container indicates potential credential theft.
Cryptocurrency mining indicators
Cryptomining is the most common payload deployed in compromised container environments. Detect high CPU usage sustained over time, network connections to mining pools, and execution of known miner binaries (xmrig, cgminer).
Network Policies
By default, all pods in a Kubernetes cluster can communicate with all other pods. This east-west permissiveness means a compromised pod can reach every other workload in the cluster. Kubernetes NetworkPolicies restrict pod-to-pod communication based on labels and namespaces. A default-deny policy that blocks all ingress and egress unless explicitly allowed, followed by allow policies for required communication paths, is the recommended approach. For clusters on AWS, Azure, or GCP, supplement Kubernetes NetworkPolicies with cloud security groups and service meshes (Istio, Linkerd) for mTLS enforcement between services.
The bottom line
Container security is a layered problem: scan images before they deploy, enforce Pod Security Admission to prevent privileged configurations, apply RBAC least privilege to service accounts, and run runtime detection to catch attacker behavior that bypasses static controls. The NSA/CISA Kubernetes Hardening Guide is the definitive reference for implementing all of these controls systematically.
Frequently asked questions
What is a container escape and how serious is it?
A container escape is an attack where code running inside a container gains access to the underlying host operating system, breaking the isolation boundary containers are supposed to provide. The severity depends on what the attacker does with host access: in cloud environments, host access often means access to cloud instance metadata (which can expose IAM credentials), access to other containers on the same host, and potentially access to the Kubernetes node's credentials. Container escapes are serious but require either a misconfigured container or a kernel vulnerability to execute.
Is Kubernetes secure by default?
No. A default Kubernetes installation has several insecure defaults: service account tokens are automatically mounted in every pod, all pods can communicate with all other pods, there are no Pod Security restrictions, the dashboard (if installed) may be accessible without authentication, and etcd may be accessible without TLS in older installations. The CIS Kubernetes Benchmark and NSA Kubernetes Hardening Guide document the configurations required to establish a secure baseline.
What is Falco and how does it work?
Falco is an open-source runtime security tool for Linux containers and Kubernetes, maintained by the CNCF. It uses eBPF or kernel module probes to intercept system calls made by containers and evaluates them against a ruleset. When a syscall matches a rule (shell spawned in container, unexpected network connection, sensitive file access), Falco generates an alert. Falco is commonly deployed as a DaemonSet so it runs on every Kubernetes node. Alerts can be forwarded to SIEM via Falcosidekick.
How do we handle secrets management in Kubernetes?
Kubernetes Secrets are base64-encoded (not encrypted) by default and accessible to any pod with the appropriate RBAC permissions. Hardening: enable etcd encryption at rest for Secrets, restrict RBAC access to Secrets to only the service accounts that need them, and use external secrets management (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) with the Secrets Store CSI Driver or External Secrets Operator to inject secrets into pods without storing them in etcd. Audit access to Secrets using Kubernetes audit logs.
What is eBPF and why is it important for container security?
eBPF (extended Berkeley Packet Filter) is a Linux kernel technology that allows running sandboxed programs in the kernel without modifying kernel source code or loading kernel modules. Container security tools (Falco, Cilium, Tetragon) use eBPF to observe system calls, network traffic, and process behavior with minimal performance overhead and without requiring agents inside containers. eBPF-based security tools are more difficult for attackers to evade than agent-based approaches because they operate at the kernel level rather than within the container namespace.
What is the CIS Kubernetes Benchmark?
The Center for Internet Security (CIS) Kubernetes Benchmark is a prescriptive configuration guide that documents specific settings for securing Kubernetes clusters. It covers API server configuration, etcd security, kubelet settings, RBAC, network policies, and audit logging. Compliance scanners (kube-bench, Trivy) can automatically check your cluster against the benchmark and report deviations. The benchmark is updated for each major Kubernetes version. Running kube-bench against your clusters is a fast way to identify the highest-priority hardening gaps.
Sources & references
- CISA Kubernetes Hardening Guidance
- NSA Kubernetes Hardening Guide v1.2
- Aqua Security 2025 Cloud Native Security Report
- Sysdig 2025 Cloud Threat Year in Review
- CIS Kubernetes Benchmark v1.8
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.