Kubernetes Pod Security Standards: What They Cover and What They Don’t
Your cluster is running with the restricted Pod Security Standard applied. Your security team is confident that Kubernetes is locked down. A compliance auditor scans your container images and finds 400 CVEs.
Both things can be true simultaneously. Pod Security Standards address one layer of the security stack. The image content is a different layer. Conflating them creates a false sense of coverage that leaves real gaps.
What Pod Security Standards Actually Control?
PSS operates at the pod specification level. It controls what privileges a container can request:
- Whether a container runs as root
- Whether it requests host network, host PID, or host IPC namespaces
- Which capabilities it can add
- Whether it can mount arbitrary host volumes
- What seccomp profile it runs under
These are meaningful controls. Running containers as non-root, restricting capabilities, and applying seccomp profiles reduce the blast radius of a compromise. A container that can’t access the host network has a harder time pivoting to infrastructure.
But none of these controls say anything about what’s inside the container image. A container running as non-root with a restrictive seccomp profile still carries every CVE in its base image. An attacker with code execution inside that container can still exploit those CVEs within the container’s security context.
PSS restricts how a container interacts with the host. It doesn’t restrict what the container itself contains.
The Gaps PSS Leaves Open
CVE content in images
Secure container software requires addressing both the pod security policy layer and the image content layer. PSS doesn’t scan images. It doesn’t have a CVE threshold. It doesn’t know what packages are installed in the container. A container running under the restricted PSS profile can still carry hundreds of unpatched vulnerabilities.
Unused packages as post-exploitation tools
PSS can prevent a container from running with privileged capabilities. It can’t prevent a container from having bash, curl, and python3 installed. An attacker who gains code execution inside a PSS-compliant container can still use living-off-the-land techniques with the tools present in the image.
Supply chain verification
PSS doesn’t verify where an image came from, whether it was signed, or whether it’s been through a hardening process. Any image—hardened or not—can be deployed in a PSS-compliant pod, as long as the pod spec meets the security requirements.
Runtime behavior deviation
PSS checks the pod specification at admission time. It doesn’t monitor whether the container’s runtime behavior changes after deployment. A container that was admitted as PSS-compliant can still exhibit anomalous runtime behavior that PSS has no mechanism to detect.
How to Fill the Gaps?
Layer image security on top of PSS, not instead of it. PSS and image hardening are complementary controls. Implement both. The restricted profile handles pod-level privilege controls. Container security software that reduces CVEs and removes unused tools handles the image content layer.
Add admission control for image attestations alongside PSS. Use Kyverno or OPA Gatekeeper to enforce image signing and hardening attestation requirements. PSS handles pod spec validation; additional admission webhooks handle image content validation. Both can run in the same cluster.
Include image scanning in your Kubernetes security baseline. When you define your security baseline for the cluster, include image scanning as a required component alongside PSS. Document the CVE threshold, the required hardening process, and the signing requirements as part of your cluster security policy.
Monitor runtime behavior against a defined baseline. PSS is a static check at admission. Runtime security monitoring that compares actual container behavior against an expected baseline catches deviations that PSS cannot observe.
Communicate the PSS coverage scope to stakeholders. Security teams, developers, and auditors should understand that PSS-compliant doesn’t mean “fully secured.” Document what PSS covers and what additional controls address the remaining gaps. This prevents the false equivalence that creates blind spots.
Frequently Asked Questions
What do Kubernetes Pod Security Standards actually cover?
Kubernetes Pod Security Standards control how containers interact with the host at the pod specification level. They govern whether a container runs as root, whether it requests host network or host PID namespaces, which Linux capabilities it can add, whether it can mount host volumes, and what seccomp profile it runs under. The three profiles—Privileged, Baseline, and Restricted—represent increasing levels of constraint on these pod-level privileges.
Do Kubernetes Pod Security Standards protect against CVEs in container images?
No. Pod Security Standards operate at the pod specification layer and have no visibility into the content of the container image itself. A container running under the restricted PSS profile with a non-root user and a restrictive seccomp profile still carries every CVE present in its base image. An attacker with code execution inside that container can still exploit those vulnerabilities within the constraints the PSS profile allows.
What security controls does PSS not cover that organizations need to address separately?
Pod Security Standards leave three significant gaps: CVE content in container images, supply chain verification, and runtime behavior monitoring. PSS does not scan images for vulnerabilities, does not verify that images came from a trusted hardened pipeline, and does not monitor whether a container’s runtime behavior changes after it is admitted. These gaps require separate controls: image scanning and hardening for CVE content, image signing and admission webhooks for supply chain verification, and runtime security monitoring for behavioral drift.
How do Pod Security Standards relate to CIS Kubernetes Benchmark compliance?
CIS Kubernetes Benchmark includes controls that align with PSS requirements—restricting privileged containers, requiring non-root execution, applying seccomp profiles. Satisfying these benchmark controls is valuable and demonstrates meaningful cluster hardening. However, a cluster that passes CIS benchmark checks can still generate audit findings for unpatched image CVEs. Compliance reviewers increasingly assess both the pod privilege controls that PSS and CIS address and the image vulnerability management program that addresses image content.
The Compliance Implication
Auditors who assess containerized environments are increasingly sophisticated about what PSS does and doesn’t cover. A cluster that passes CIS Kubernetes Benchmark checks—which includes PSS controls—will still generate audit findings for unpatched image CVEs.
The PSS controls satisfy the “privilege restriction” controls in CIS and NIST frameworks. They don’t satisfy vulnerability management requirements. Those require a separate program: scanning, hardening, evidence collection, and tracked remediation.
Teams that treat PSS as their complete container security program will encounter this gap in compliance reviews. The auditors find CVEs that PSS was never designed to address. The response—”but we have PSS enabled”—doesn’t satisfy the finding.
A mature Kubernetes security program addresses both layers. PSS handles pod-level privileges. Image hardening and vulnerability management handle image content. Together, they satisfy a compliance reviewer who understands both layers of the stack.