| name | apply-kubernetes-security |
| description | Use when deploying workloads to Kubernetes — configuring RBAC, network policies, pod security standards, secrets management, and admission controls to prevent privilege escalation and lateral movement. |
| source | OWASP Kubernetes Security Cheat Sheet (owasp.org/www-project-cheat-sheets); CIS Kubernetes Benchmark; NIST SP 800-190; Kubernetes Pod Security Standards documentation |
| tags | ["security","owasp","kubernetes","rbac","containers","devops","developer"] |
Apply Kubernetes Security
Harden Kubernetes clusters by enforcing RBAC least privilege, network policies, pod security standards, and encrypted secrets — preventing privilege escalation, lateral movement, and container escape.
Why This Is Best Practice
Adopted by: OWASP Kubernetes Security Cheat Sheet and CIS Kubernetes Benchmark v1.8 are the authoritative references. NSA/CISA released "Kubernetes Hardening Guidance" (2022) as official federal guidance. Google GKE Autopilot, AWS EKS default node groups, and Azure AKS enforce pod security admission and RBAC by default. Kubernetes Pod Security Standards (PSS) replaced PodSecurityPolicy in K8s 1.25 and are now the built-in hardening mechanism.
Impact: The 2022 Tesla cryptojacking incident and the 2020 SolarWinds supply chain attack both involved misconfigured Kubernetes clusters with over-permissive RBAC. Palo Alto Unit 42 (2022) found 65% of Kubernetes clusters in production had at least one container running as root. NSA/CISA guidance found that default Kubernetes configurations grant excessive permissions that enable cluster-wide lateral movement from a single compromised pod.
Why best: Default Kubernetes configuration prioritizes compatibility over security — default service accounts have API access, pods can communicate freely, and secrets are stored as base64 (not encrypted). Applying RBAC least privilege, network policies, and pod security standards systematically closes these gaps vs. relying on application-level controls alone.
Sources: OWASP Kubernetes Security Cheat Sheet; CIS Kubernetes Benchmark v1.8; NSA/CISA Kubernetes Hardening Guidance (2022); Kubernetes Pod Security Standards documentation
Steps
-
Enforce Pod Security Standards at the namespace level:
kubectl label namespace production \
pod-security.kubernetes.io/enforce=restricted \
pod-security.kubernetes.io/enforce-version=latest \
pod-security.kubernetes.io/warn=restricted \
pod-security.kubernetes.io/audit=restricted
apiVersion: v1
kind: Pod
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
seccompProfile:
type: RuntimeDefault
containers:
- name: app
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
resources:
limits:
cpu: "500m"
memory: "256Mi"
requests:
cpu: "100m"
memory: "128Mi"
-
Apply RBAC least privilege — never use cluster-admin for workloads:
apiVersion: rbac.authorization.k8s.io/v1
[]
[]
[, ]
Rules
- Never bind
cluster-admin to a service account used by an application workload.
- Disable
automountServiceAccountToken: false on every pod that doesn't call the Kubernetes API.
- Network policies require a CNI plugin that enforces them (Calico, Cilium, Weave) — vanilla kubenet ignores NetworkPolicy objects.
- etcd must be encrypted at rest and accessible only to the API server — direct etcd access bypasses all RBAC.
Common Mistakes
securityContext at pod level vs container level — runAsNonRoot must be set at both levels; container-level overrides pod-level.
- Storing secrets as environment variables — environment variables appear in
kubectl describe pod and process listings; use volume mounts.
- No resource limits — a pod without limits can starve the node; resource limits are also required for
restricted pod security standard.
- Using
hostNetwork: true or hostPID: true — gives the container access to the host network stack and process namespace, defeating isolation.