A misconfigured pod is the fastest way into a Kubernetes cluster. In 2018, attackers found Tesla's Kubernetes dashboard exposed with no password, walked in through an unauthenticated pod, and used it to mine cryptocurrency on Tesla's own compute. In 2021, security researchers at Unit 42 discovered Siloscape, malware purpose-built to escape Windows containers and pivot into the underlying Kubernetes cluster through overly permissive pods. Neither attack required a zero-day. Both exploited pods that were allowed to run as root, mount the host filesystem, or reach the Kubernetes API with more privilege than the workload needed.
Kubernetes pod security is the set of controls -- security contexts, Pod Security Standards, network policies, and admission control -- that determine what a pod and its containers are allowed to do on a node and in a cluster. Get it wrong, and a single compromised container can become a compromised node, namespace, or cluster. This glossary entry breaks down what pod security actually covers, what changed after PodSecurityPolicy was removed, and where teams still get it wrong in 2026.
What Is Kubernetes Pod Security?
Kubernetes pod security is the practice of restricting what a pod can do at runtime -- which user it runs as, what it can mount, what Linux capabilities it holds, and whether it can escalate privileges on the host. Every pod spec includes fields (securityContext, hostNetwork, hostPID, volumes) that either lock a container down to only what it needs or leave it with default Linux capabilities that go well beyond what most applications require. A pod running as UID 0 with allowPrivilegeEscalation: true and a hostPath mount to / is functionally equivalent to giving that container root on the node. Pod security is the layer that prevents that by default rather than by exception, enforced through three mechanisms: pod-level security contexts set by developers, Pod Security Standards enforced by the cluster, and network policies that restrict what a pod can talk to once it's running.
What Replaced PodSecurityPolicy, and Why Does It Matter?
Pod Security Admission (PSA) replaced PodSecurityPolicy (PSP), which was deprecated in Kubernetes v1.21 (April 2021) and fully removed in v1.25 (August 2022). PSP required writing and maintaining a separate, cluster-scoped RBAC-bound resource for every policy tier, which most teams found confusing enough that adoption stayed low even while it was the only built-in option. PSA replaced it with three built-in profiles applied as namespace labels: privileged (no restrictions), baseline (blocks known privilege escalations like host namespace sharing), and restricted (enforces current pod hardening best practice, including non-root execution and dropped capabilities). Any cluster still running v1.24 or earlier and relying on PSP needs a migration plan before that control disappears on upgrade -- clusters that skipped the migration and later upgraded to v1.25+ silently lost their only pod-level admission control, often without anyone noticing until an audit.
What Are the Most Common Pod Security Misconfigurations?
The most common misconfiguration is running containers as root with no user override, which multiple industry surveys have consistently found in over half of production container images. Beyond root execution, four patterns show up repeatedly in cluster audits: containers with privileged: true set for debugging and never reverted; pods with hostPath volumes mounting sensitive host directories like /var/run/docker.sock or /etc; missing resource limits, which lets a single pod exhaust node CPU or memory and take down co-located workloads; and default service account tokens auto-mounted into every pod, giving any compromised container a live credential to the Kubernetes API even when the workload never calls it. Red Hat's State of Kubernetes Security research has repeatedly found that a majority of surveyed organizations experienced at least one security incident in their Kubernetes environments over the prior 12 months, and misconfiguration -- not a novel exploit -- was the leading cause each time the survey ran.
How Do Security Contexts and Pod Security Standards Work Together?
Security contexts set the behavior of an individual pod or container, while Pod Security Standards set the floor that every pod in a namespace must meet. A developer's securityContext block can specify runAsNonRoot: true, readOnlyRootFilesystem: true, and capabilities.drop: ["ALL"] for a single pod, but nothing forces every team to write that block correctly, or at all. Pod Security Admission closes that gap at the namespace level: label a namespace pod-security.kubernetes.io/enforce: restricted and the API server rejects any pod that doesn't meet the restricted profile before it's ever scheduled -- no root UID, no privilege escalation, no adding capabilities beyond the default set. This two-layer model is why both matter: security contexts are the mechanism, Pod Security Standards are the guardrail that catches the pods where the mechanism was skipped.
What Real-World Incidents Have Exploited Weak Pod Security?
Weak pod security has enabled cluster takeovers, cryptomining campaigns, and container escapes documented across multiple public incidents. The Tesla dashboard breach (2018) started with an exposed, unauthenticated Kubernetes dashboard that gave attackers direct pod access and cluster credentials, which they used to deploy cryptomining containers. CVE-2019-5736, a runc container escape, allowed a malicious or compromised container to overwrite the host runc binary and execute code on the node -- a scenario security contexts that block privilege escalation and enforce read-only root filesystems would have contained. Siloscape (2021) targeted misconfigured Windows containers specifically to reach the Kubernetes API server and pivot laterally across an entire cluster rather than staying contained to one pod. Each of these traces back to the same root cause: a pod with more privilege, network reach, or host access than its workload actually required.
How Safeguard Helps
Safeguard maps pod security risk to what actually matters in a running cluster instead of flagging every deviation from a hardening checklist. Reachability analysis identifies which containers running as root, privileged, or with host mounts are actually exposed to untrusted input or external traffic, so teams fix the pods that create real attack paths first. Griffin AI, Safeguard's security reasoning engine, correlates pod-level misconfigurations with the base image, dependency, and runtime context to explain why a given security context gap is exploitable in this specific deployment. Safeguard generates and ingests SBOMs across container images to track what's actually running inside every pod, and where a fix is available, it opens an auto-fix PR that adds the missing securityContext fields or Pod Security Standard labels directly against the source manifest.