Chapter 32 Key Takeaways: Container and Kubernetes Security

Core Concepts

1. Containers Are Not Virtual Machines Containers share the host operating system kernel, relying on namespaces and cgroups for isolation rather than hardware virtualization. This fundamental architectural reality means that a kernel exploit inside a container can compromise the host. Penetration testers must evaluate container isolation as a software boundary, not a hardware one.

2. Image Security Is the Foundation Container security begins long before runtime. Vulnerable base images, embedded secrets in image layers, and supply chain compromises at the build stage propagate through every deployment. Always inspect all image layers—secrets "deleted" in later layers persist in earlier ones and can be extracted.

3. Docker Runtime Misconfigurations Create Critical Vulnerabilities Privileged containers, mounted Docker sockets, host namespace sharing, and excessive capabilities each provide direct paths to container escape and host compromise. These misconfigurations are commonly found in production environments and represent some of the highest-impact findings in container assessments.

4. Container Escapes Are Real and Practical Container escapes through privileged mode, Docker socket access, kernel vulnerabilities, and cgroup manipulation are well-documented and exploitable. Penetration testers should systematically check for escape vectors from within any compromised container.

5. Kubernetes RBAC Is Frequently Misconfigured Overpermissioned service accounts, wildcard permissions, default service account usage, and cluster-admin bindings to workload service accounts are among the most common findings. Always enumerate permissions from within compromised pods using kubectl auth can-i --list.

6. Kubernetes Secrets Require Active Security Design Secrets are base64-encoded by default, not encrypted. Without encryption at rest for etcd, strict RBAC controls, and external secret management, Kubernetes Secrets offer minimal protection. Treat secret management as a first-class security concern.

7. Network Policies Are the Exception, Not the Rule Most Kubernetes clusters lack network policies, allowing unrestricted pod-to-pod communication across all namespaces. This makes lateral movement trivial after any pod compromise. The absence of network policies should be reported as a significant finding.

8. Supply Chain Attacks Target the Trust Chain Compromised CI/CD tools, poisoned base images, and tampered registries can silently affect thousands of deployments. Defend with image signing, digest pinning, SBOM generation, and admission controllers that enforce provenance verification.

9. Cloud Integration Extends the Attack Surface Managed Kubernetes services interact with cloud IAM, metadata services, and provider APIs. A compromised pod can access the Instance Metadata Service to obtain cloud credentials, pivoting from container access to cloud environment access without ever escaping the container.

10. Defense Requires Depth Across the Entire Lifecycle Effective container security spans image building, registry management, deployment admission, runtime monitoring, and incident response. No single control is sufficient. The Tesla and Codecov incidents demonstrate that a single missing control in an otherwise reasonable security posture can lead to full compromise.

Practical Reminders

⚠️ Always verify your authorization scope before testing container escapes. Escaping a container in a shared environment could affect other tenants.

💡 Use tools like kube-bench (CIS compliance), kube-hunter (penetration testing), Trivy (vulnerability scanning), and Falco (runtime monitoring) as part of your container security assessment toolkit.

🔵 When reporting container and Kubernetes findings, map them to the CIS Kubernetes Benchmark and the NSA/CISA Kubernetes Hardening Guide for standardized remediation guidance that clients can action directly.