Whoever writes the Deployment decides how much of the node and the cluster a compromised container can reach. A pod that runs as root with default capabilities, an API token it never uses and the Unconfined seccomp default turns an application bug into a container escape or a cluster foothold.
- Set
securityContextfor every container: a non-root user,allowPrivilegeEscalation: false,capabilities.drop: [ALL], a read-only root filesystem and theRuntimeDefaultseccomp profile. - Set
automountServiceAccountToken: falseunless the application calls the Kubernetes API. - Avoid
privileged: true, host namespaces and host paths; where a workload genuinely needs one, record the exception and isolate it. - Set CPU and memory limits, and enforce the Pod Security Standards Restricted profile at admission so a manifest cannot quietly drop these settings.
Guides on this site
Run Kubernetes workloads with only the privileges they need
Review pod settings, service accounts and effective permissions together before treating a namespace as an isolation boundary.
Harden managed Kubernetes on EKS, AKS and GKE
Know what your provider secures and what you still own, then lock down API access, cloud identity, nodes, pod privileges and admission with settings that are generally available in Kubernetes 1.37, checked against the CIS and NSA/CISA baselines.
Harden container images from Dockerfile to admission
Build minimal, non-root images pinned by digest, keep secrets out of every layer, then scan, sign and verify the exact digest before it runs with dropped privileges.
Practice
- Privileged container lab: Reject a privileged workload before deployment · Browser lab
- NetworkPolicy lab: Lock down a shop namespace · Browser lab
- Verify Kubernetes admission and network boundaries · Local project
- Repair a security pipeline for GitHub Actions and GitLab CI · Local project
- Gate an image build on a CIS scan and a deviation register · Local project
References
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.
OWASP does not publish a mapping between the 2022 and 2025 lists. The 2022 entry shown for each risk is the one with the same subject, matched by title; 2022's K02 Supply Chain Vulnerabilities has no 2025 counterpart.