Your cluster is running with a mix of pod security configurations. Some namespaces enforce restricted. Some are still on baseline. A few have exceptions that haven’t been reviewed since they were granted. Meanwhile, developers are complaining that security requirements are blocking legitimate deployments.
This is where most Kubernetes pod security programs get stuck. The standards exist. Enforcement is inconsistent. Exceptions accumulate.
The problem isn’t the standard itself. It’s that security contexts and container images are treated as separate concerns when they’re deeply connected.
Why PSS Enforcement Breaks Workloads?
The restricted Pod Security Standard requires containers to run as non-root, drop all capabilities, set a read-only root filesystem, and use a restrictive seccomp profile. These are correct requirements. They’re also requirements that many container images weren’t designed to meet.
Container images that assume root access for startup scripts will fail under restricted. Images that bind to privileged ports will fail. Images that need write access to their filesystem for logging or caching will fail on the read-only filesystem requirement.
The typical response to these failures is namespace-level exceptions. Apply baseline or privileged to namespaces where workloads can’t meet restricted. Over time, the exception namespaces accumulate. The cluster that was supposed to be running under restricted is actually running most workloads under much weaker standards.
Pod security exceptions granted for image incompatibilities are an image problem dressed as a policy problem.
How Image Hardening Makes PSS Enforcement Practical?
Images that don’t need root
Container security for production workloads should default to non-root execution. This means the application process is configured to run as a non-root user in the container. Hardened images built for restricted compliance have this configured by default.
When images are built to run as non-root, restricted enforcement stops being an adversarial requirement and becomes a verification that the image was built correctly.
Removed binaries that require elevated capabilities
Some binaries in container base images require Linux capabilities that restricted doesn’t allow. When hardening removes those binaries—because they’re not needed at runtime—the image no longer requires the capabilities they need. The PSS restriction becomes compatible with the image by construction.
Read-only filesystem compatibility
The hardened image should not need to write to its own filesystem in production. Application logs should go to stdout/stderr. Cache directories should use mounted volumes if needed. An image that writes only to explicitly mounted paths can run with a read-only root filesystem, satisfying a key restricted requirement.
Container hardening as PSS pre-compliance
When image hardening is done with PSS compliance as a target, the resulting images work under restricted without exceptions. The enforcement doesn’t break deployments because the images were built to meet the requirements.
Practical Steps for PSS Adoption
Audit existing workloads against restricted before enforcing. Use kubectl label namespace –dry-run with PSS enforcement to identify which workloads would fail under restricted. Categorize failures by root cause: image incompatibility vs. legitimate capability needs.
Fix image incompatibilities through hardening, not through exceptions. For each workload that fails restricted because of image design—root execution, writable filesystem, unnecessary capabilities—fix the image. This may require working with the application team, but it’s the right fix. Exceptions should be reserved for workloads with genuine capability requirements, not image design debt.
Apply restricted progressively by namespace risk level. Start with namespaces running non-critical workloads. Enforce restricted, fix what breaks, learn from the failures, then move to higher-risk namespaces with that knowledge.
Build PSS compliance into your image standards. When you define what a “production-ready” image means in your organization, include PSS restricted compatibility. New services start from base images that are already compatible, rather than needing remediation after the fact.
Set a date for exception expiration. Every PSS exception should have an expiration date and a remediation plan. Exceptions granted with no expiration date become permanent. Quarterly exception reviews drive toward the default state being restricted across the cluster.
Frequently Asked Questions
What are Kubernetes Pod Security Standards and what does the restricted profile require?
Kubernetes Pod Security Standards (PSS) are built-in policy frameworks that define security requirements for pods. The restricted profile—the most secure tier—requires containers to run as non-root, drop all Linux capabilities, use a read-only root filesystem, and apply a restrictive seccomp profile. These requirements significantly limit the attack surface of running workloads but are incompatible with many container images that were built without these constraints in mind.
Why does enforcing Kubernetes pod security best practices break existing workloads?
Many container images assume root access for startup scripts, bind to privileged ports, or write to their own filesystem for logging and caching. These design choices are incompatible with the restricted Pod Security Standard. When organizations try to enforce restricted without first addressing image design, the result is that legitimate workloads fail admission—leading to namespace-level exceptions that accumulate until the cluster is effectively running under much weaker standards.
How does container image hardening make Kubernetes pod security enforcement practical?
Hardening produces images that are built to meet PSS restricted requirements by default—configured to run as non-root, removing binaries that require elevated capabilities, and routing application output to stdout/stderr rather than the container filesystem. When images are built this way, restricted enforcement stops blocking legitimate deployments because the images were designed to pass those checks from the start.
How should organizations progressively adopt Kubernetes pod security best practices across a cluster?
Start by auditing existing workloads against restricted using dry-run enforcement to identify which workloads would fail and why. Fix image incompatibilities through hardening rather than granting exceptions. Apply restricted progressively, starting with non-critical namespaces to learn from failures before moving to higher-risk environments. Set expiration dates on every exception and build PSS restricted compatibility into the definition of a production-ready image for new services.
The Compounding Security Benefit
Teams that have achieved broad restricted PSS enforcement across their cluster report that the security benefits extend beyond the specific controls the standard imposes. The process of making workloads PSS-compatible forces reviews of image design, runtime requirements, and security context configuration that frequently uncover other security issues.
An image that runs as root because “it always has” often turns out to have no actual need for root. The PSS enforcement is the forcing function that surfaces this. Fixing it improves the workload’s security posture beyond the specific PSS requirement.
The organizations furthest ahead on Kubernetes security posture are the ones that treated PSS enforcement as a project, not a switch. They inventoried their workloads, fixed their images, established standards for new services, and drove exceptions to near-zero over 12-18 months. That investment compounds—new services start compliant rather than starting insecure and requiring remediation.