A Practical Guide to Kubernetes Pod Security Standards

Kubernetes provides powerful orchestration capabilities, but its default configuration prioritizes flexibility over strict security. A single misconfigured Pod can enable privilege escalation or broader cluster compromise. To mitigate this risk, Kubernetes includes Pod Security Standards (PSS)—a built-in framework for enforcing security best practices at the workload level.

This guide focuses on practical implementation. It shows how to enforce Pod Security Standards using the native Pod Security Admission controller, configure policies at the namespace level, and use non-enforcing modes such as audit and warn to roll out controls safely without disrupting existing workloads.

Key takeaways:

• Use the three PSS profiles for tiered security: Apply the Baseline profile as a default for most applications, enforce the Restricted profile for production workloads, and reserve the Privileged profile only for essential system components that require elevated permissions.
• Roll out policies without breaking applications: Start with the audit and warn modes to gather insights on non-compliant workloads. This allows you to identify necessary application changes before switching to enforce mode, preventing unexpected disruptions.
• Automate policy enforcement to maintain consistency: Manually configuring security across many clusters is error-prone. Use a centralized platform like Plural with GitOps workflows and Global Services to apply consistent Pod Security Standards across your entire fleet, eliminating configuration drift.

What Are Kubernetes Pod Security Standards?

Kubernetes Pod Security Standards (PSS) define a set of predefined security profiles that enforce isolation and hardening rules for Pods. They provide a consistent way to apply baseline security controls across workloads without requiring custom policy definitions. PSS replaces the deprecated PodSecurityPolicy (PSP) system with a simpler model built around three predefined profiles that represent increasing levels of restriction.

PSS itself is a specification, not a policy engine. Enforcement is performed by the built-in Pod Security Admission controller, which validates Pod configurations against the selected security profile. This model allows clusters to enforce common security controls—such as restricting privileged containers, host namespace usage, and unsafe capabilities—using standardized policies.

The Shift from PodSecurityPolicy

PodSecurityPolicy (PSP) allowed cluster administrators to define fine-grained security controls, but the system was complex and error-prone. PSPs required multiple resources, RBAC bindings, and careful ordering of policy evaluation, which often led to misconfigurations or unexpected deployment failures.

To address these operational challenges, PSP was deprecated in Kubernetes v1.21 and fully removed in Kubernetes v1.25. The replacement approach focuses on predefined security profiles enforced by the Pod Security Admission controller. This significantly reduces configuration complexity while still covering the most common Pod security requirements.

How Pod Security Standards Work

Pod Security Standards are enforced by the Pod Security Admission controller. When a Pod is created or updated, the controller evaluates its configuration against the security profile assigned to the namespace.

PSS defines three security profiles:

• Privileged – No restrictions. Pods can use privileged containers and host namespaces.
• Baseline – Prevents known privilege-escalation vectors while allowing common workloads.
• Restricted – Enforces strong hardening, including non-root containers and limited capabilities.

Policies are applied at the namespace level using labels. Every Pod created in that namespace is validated against the configured profile. This approach simplifies policy management because administrators do not need to define security policies per workload.

Key Benefits Over Legacy Security

The main advantage of Pod Security Standards over PSP is operational simplicity. Instead of designing and maintaining custom policies, teams can adopt predefined security profiles that cover common hardening requirements.

This approach provides several practical benefits:

• Lower configuration complexity compared to PSP.
• Predictable security levels using standardized profiles.
• Namespace-level enforcement that simplifies policy management.
• Gradual rollout support through audit and warning modes.

For most clusters, PSS provides a straightforward baseline for workload hardening while keeping operational overhead low. Teams that require more granular policy control can still layer additional tools—such as OPA Gatekeeper or Kyverno—on top of the built-in admission controls.

What Are the Three Pod Security Standard Profiles?

Kubernetes Pod Security Standards define three predefined security profiles: Privileged, Baseline, and Restricted. These profiles represent progressively stricter security controls for Pods. Instead of designing custom policies, platform teams select a profile that matches the trust level and operational needs of the workloads running in a namespace.

The profiles provide a practical security gradient. Infrastructure components that require deep host access can run under Privileged, general application workloads typically fit Baseline, and hardened production workloads should target Restricted. Because enforcement is applied at the namespace level through the Pod Security Admission controller, every Pod created in that namespace must comply with the selected profile.

Privileged: For Trusted System Workloads

The Privileged profile imposes no restrictions on Pod configuration. Containers can run in privileged mode, access host namespaces, mount host paths, and use unrestricted Linux capabilities.

This profile is intended for infrastructure components that require direct interaction with the host system. Examples include:

• CNI networking plugins
• CSI storage drivers
• Node-level monitoring or security agents

Using this profile effectively disables Pod Security enforcement for the namespace. It should therefore be limited to tightly controlled system namespaces where workloads are trusted and audited.

Baseline: For Standard Application Workloads

The Baseline profile blocks common privilege-escalation paths while still allowing typical containerized applications to run without major modification.

Baseline policies prevent risky configurations such as:

• Privileged containers
• Host networking and host PID/IPC namespaces
• Certain sensitive host path mounts
• Adding dangerous Linux capabilities

This profile provides a reasonable default for most application namespaces. It protects against well-known container escape vectors while maintaining compatibility with common deployment patterns.

Restricted: For Hardened Production Workloads

The Restricted profile enforces strong workload hardening aligned with container security best practices. It applies a strict least-privilege model that significantly limits what containers can do.

Typical requirements under the Restricted profile include:

• Containers must run as a non-root user
• Privilege escalation is disabled
• A seccompProfile must be defined
• Linux capabilities are tightly restricted
• Unsafe volume types and host access are blocked

Some applications may require configuration changes to comply with these constraints. However, Restricted represents the desired target for security-sensitive production environments.

Choosing the Right Profile

Selecting the appropriate profile involves balancing security requirements with operational constraints.

A common deployment pattern looks like this:

• Privileged for system namespaces and infrastructure components
• Baseline as the default for most application namespaces
• Restricted for hardened production workloads or sensitive services

Applying these profiles consistently across clusters reduces the attack surface of containerized workloads. Platforms such as Plural help enforce these standards at scale by applying consistent RBAC and security policies across clusters, reducing configuration drift and maintaining compliance.

How to Enforce Pod Security Standards

Use the Built-in Pod Security Admission Controller

Pod Security Standards are enforced through the Pod Security Admission (PSA) controller, which runs inside the Kubernetes API server. The controller evaluates Pod creation and update requests against the security profile assigned to the namespace. If the Pod specification violates the selected profile, the request can be rejected or flagged depending on the enforcement mode.

Because PSA is a native Kubernetes feature, no additional components are required. Once enabled (it is enabled by default in modern Kubernetes releases), clusters can enforce Pod Security Standards without installing third-party admission controllers.

Configure Policies at the Namespace Level

Pod Security policies are applied at the namespace level using labels. Every Pod created within the namespace is evaluated against the configured profile.

Example: enforcing the baseline profile for a namespace.

kubectl label namespace production \
  pod-security.kubernetes.io/enforce=baseline

You can also specify the policy version to ensure consistent enforcement across Kubernetes upgrades:

kubectl label namespace production \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/enforce-version=latest

Managing these labels consistently across many clusters can become operationally difficult. Platforms such as Plural help enforce namespace-level security policies across clusters by synchronizing configuration and preventing drift.

Apply Enforcement Modes: Enforce, Audit, and Warn

PSA supports three enforcement modes that allow teams to roll out policies gradually:

• enforce – Rejects Pods that violate the selected profile.
• warn – Allows the Pod but returns warnings to the user during creation.
• audit – Allows the Pod and records violations in the Kubernetes audit log.

A common rollout strategy is:

1. Start with audit to identify violations.
2. Add warn so developers see violations during deployment.
3. Move to enforce once workloads are compliant.

Example namespace configuration:

kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted

This staged approach allows teams to evaluate existing workloads before enforcing strict policies.

Use Policy Engines for Advanced Controls

Pod Security Admission enforces standardized profiles, but it cannot express arbitrary policy logic. For more advanced controls, many organizations deploy policy engines such as OPA Gatekeeper or Kyverno.

These tools allow custom admission policies, for example:

• Enforcing approved container registries
• Requiring specific labels or annotations
• Restricting container images by digest
• Enforcing organization-specific compliance rules

While these engines provide greater flexibility, they introduce additional operational overhead. Platforms like Plural simplify deploying and managing policy engines across clusters, allowing teams to apply advanced security policies consistently across their Kubernetes environments.

Common Challenges When Implementing Pod Security Standards

Pod Security Standards (PSS) simplify workload hardening compared to the deprecated PodSecurityPolicy model, but adoption still introduces operational challenges. Teams often encounter friction when enforcing stricter policies across existing workloads, particularly in large clusters with diverse applications. The most common issues fall into four areas: application compatibility, knowledge gaps, policy fragmentation, and ongoing compliance monitoring.

Configuration Complexity and Application Compatibility

Applying stricter profiles—especially Restricted—often exposes assumptions baked into existing applications. Many legacy workloads expect elevated privileges, such as running as root, adding Linux capabilities, or accessing host resources.

When these configurations violate a security profile, Pod creation fails under enforcement mode. Teams then need to either:

• Refactor the application to comply with least-privilege constraints
• Run the workload under a less restrictive profile
• Introduce additional policy exceptions

In practice, moving workloads toward the Restricted profile requires incremental remediation: defining securityContext, dropping unnecessary capabilities, and ensuring containers run as non-root users.

Skill Gaps and Developer Awareness

Pod Security Standards surface low-level Linux security primitives that many application developers are unfamiliar with. Concepts such as seccomp, Linux capabilities, runAsUser, or allowPrivilegeEscalation can become blockers when deployments suddenly fail under stricter policies.

Without clear guidance, security enforcement can slow development workflows. Teams typically address this by:

• Providing secure workload templates
• Embedding securityContext defaults into Helm charts or deployment manifests
• Documenting compliant container patterns

Building this knowledge into the development workflow reduces friction when stricter profiles are introduced.

Policy Fragmentation Across Security Tools

While Pod Security Admission covers common workload hardening rules, many organizations also deploy additional policy engines such as OPA Gatekeeper or Kyverno. These tools enforce custom admission policies that go beyond the standard PSS profiles.

Running multiple policy layers can introduce operational complexity:

• Policies may overlap or conflict
• Admission failures may be difficult to trace
• Policy ownership may become unclear

Maintaining clear boundaries between PSS enforcement and custom policy engines is important to avoid an overly fragmented security model.

Continuous Monitoring and Compliance

Enabling Pod Security Standards is only the first step. Maintaining compliance requires continuous monitoring of policy violations and configuration drift.

During rollout, audit and warn modes can generate large volumes of events and audit log entries. These signals must be collected and analyzed to identify non-compliant workloads before enforcement is enabled.

At scale—particularly across many clusters—centralized visibility becomes essential. Platforms such as Plural help standardize security policies and configurations across clusters, reducing drift and making it easier to track policy compliance across the entire Kubernetes fleet.

Best Practices for Implementing Pod Security Standards

Implementing Pod Security Standards requires a phased rollout that minimizes disruption while improving workload security. The most effective approach focuses on gaining visibility into current workloads, gradually introducing stricter policies, and automating validation earlier in the development lifecycle. This allows teams to harden clusters without blocking deployments or breaking existing services.

Start with Audit and Warn Modes

Before enforcing a security profile, first measure how existing workloads behave under stricter policies. The Pod Security Admission controller provides audit and warn modes for this purpose.

• warn returns warnings to users during deployment when a Pod violates a policy.
• audit records violations in the Kubernetes audit logs without blocking the workload.

A common practice is to configure these modes to the target security profile—often restricted—while keeping enforcement disabled. This allows teams to identify non-compliant workloads and estimate the remediation effort required before enabling strict enforcement.

Use a Gradual Migration Strategy

Moving directly to strict enforcement can break running workloads. Instead, migrate workloads incrementally based on the violations identified during the audit phase.

Typical remediation steps include:

• Defining a securityContext
• Setting allowPrivilegeEscalation: false
• Running containers as non-root users
• Dropping unnecessary Linux capabilities
• Defining a seccompProfile

Remediation can be applied namespace-by-namespace or service-by-service. This phased rollout allows application teams to update deployment manifests without impacting production stability.

Validate Configurations with Static Analysis

The most reliable way to enforce security policies is to detect violations before manifests reach the cluster. Static analysis tools can scan Kubernetes manifests and Infrastructure-as-Code during CI.

Common tools include:

• Checkov
• Terrascan
• KubeLinter

These tools detect misconfigurations such as privileged containers, missing securityContext settings, or unsafe volume mounts. Integrating these checks into CI/CD pipelines ensures developers receive immediate feedback during pull requests.

Within Plural, these validation steps can be integrated into GitOps workflows using Plural Stacks, allowing manifest scanning and policy checks to run automatically during repository changes.

Continuously Monitor Policy Compliance

Security policies require ongoing monitoring to ensure workloads remain compliant over time. New deployments, configuration changes, or infrastructure updates can introduce policy violations.

Effective monitoring typically includes:

• Aggregating Pod Security audit events
• Tracking policy violations across namespaces
• Detecting configuration drift across clusters

Kubernetes Security Posture Management (KSPM) tools can automate these checks. Platforms like Plural provide centralized visibility across clusters, making it easier to monitor Pod Security policies, enforce consistent configuration, and identify deviations from established security standards.

Manage Pod Security Standards at Scale with Plural

Implementing Pod Security Standards is a critical step in securing your workloads, but enforcement becomes a significant challenge as your Kubernetes fleet grows. Manually configuring policies across dozens or hundreds of clusters is inefficient and prone to human error, leading to inconsistent security postures and configuration drift. A single misconfigured namespace can expose your entire environment to risk. To maintain security and compliance effectively, you need a centralized, automated approach to policy management.

Plural provides a unified platform to manage Pod Security Standards consistently across your entire infrastructure. By leveraging a GitOps-based workflow and a centralized control plane, Plural ensures that security policies are defined once and applied everywhere. This approach eliminates the operational burden of manual configuration and provides platform teams with the tools to enforce, monitor, and audit security standards at scale. Plural’s architecture allows you to manage policies for clusters running in any cloud or on-premise environment from a single interface, ensuring that every workload, regardless of its location, adheres to your organization's security requirements.

Enforce Policies Centrally Across Your Fleet

Plural enables platform teams to enforce Pod Security Standards from a single control plane, ensuring consistent application across all managed clusters. The native Kubernetes Pod Security Admission controller works by applying security profiles to namespaces. With Plural, you can define these namespace labels and other policy configurations within a Git repository. Plural’s continuous deployment engine automatically detects changes and syncs them to the target clusters. This GitOps-driven workflow creates a declarative source of truth for your security policies, preventing configuration drift and guaranteeing that every new and existing namespace complies with the required security profile without manual intervention.

Use Global Services for Consistent Security Configurations

Managing namespace labels and related security configurations across a large fleet can be complex. Plural’s Global Services feature simplifies this process by allowing you to define a configuration once and replicate it across multiple clusters. You can create a single GlobalService resource that specifies the desired Pod Security Standard labels for your namespaces. Plural then ensures this configuration is applied consistently everywhere, whether you have ten clusters or a thousand. This approach is ideal for enforcing a baseline security posture across all application namespaces or applying restricted profiles to production environments, drastically reducing administrative overhead and ensuring uniformity.

Automate Compliance with a Unified Dashboard

Enforcement is only one part of the equation; visibility is essential for maintaining compliance. Plural provides a single-pane-of-glass console that offers a centralized view of your entire Kubernetes fleet. From this dashboard, you can audit namespaces to verify that the correct Pod Security Standards are being applied and review audit logs for policy violations. This unified visibility allows you to quickly identify non-compliant workloads and address security gaps before they become critical vulnerabilities. By automating the monitoring process, Plural helps your team shift from a reactive to a proactive security posture, ensuring continuous compliance across your infrastructure.

Streamline RBAC with SSO Integration

Effective security policy management requires robust access control. Plural simplifies Kubernetes RBAC by integrating directly with your existing SSO provider. Instead of juggling individual kubeconfigs, you can manage permissions using your organization’s established user identities and groups. Plural’s embedded Kubernetes dashboard uses impersonation to authenticate API requests, meaning all RBAC policies resolve to your console user’s email and group affiliations. This allows you to create ClusterRoleBindings that grant permissions to entire teams, such as an SRE group, ensuring that access is both secure and easy to manage at scale.

Related Articles

• Kubernetes Pod vs. Container: What You Must Know
• Kubernetes Cluster Security: A Deep Dive

Frequently Asked Questions

I have a lot of existing applications. How do I introduce Pod Security Standards without breaking everything? The key is to start with visibility, not enforcement. Begin by applying your target policy, like restricted, in warn and audit modes across your namespaces. This approach allows your applications to continue running without interruption while generating valuable data. You can then analyze the warnings and audit logs to identify which specific workloads violate the policy. This gives you a clear, prioritized list of applications that need to be updated, allowing you to work with development teams on a gradual migration plan instead of causing a sudden, widespread outage.

Is the 'Restricted' profile the ultimate goal for all my production workloads? While the 'Restricted' profile represents the gold standard for security, it's not always a practical fit for every single application. Some workloads, particularly system components or legacy applications, may have legitimate needs that conflict with its strict rules. The goal is to apply the most restrictive profile that an application can support. A good strategy is to make 'Restricted' the default target for all new applications while using the 'Baseline' profile as a solid, secure foundation for workloads that cannot be easily refactored.

Can I use Pod Security Standards alongside a more advanced policy engine like OPA Gatekeeper? Yes, and this is a common pattern in mature Kubernetes environments. Pod Security Standards are excellent for establishing a foundational security baseline across all your clusters with minimal overhead. You can then layer a tool like OPA Gatekeeper or Kyverno on top to enforce more complex, custom business logic. For example, you could use PSS to enforce the 'Baseline' profile everywhere, and then use Gatekeeper to add a specific rule that all container images must come from your organization's trusted registry.

What's the most common mistake teams make when first implementing PSS? The most frequent misstep is moving directly to enforce mode without first gathering data. Teams are often eager to lock down their environments, but applying a restrictive policy without understanding its impact can break critical applications and create friction with developers. This leads to emergency rollbacks and a loss of confidence in the security initiative. Always start with the non-blocking audit and warn modes to ensure a smooth, data-driven rollout.

How does Plural help if we already have a GitOps workflow for managing our cluster configurations? Plural enhances your existing GitOps workflow by providing centralized management and enforcement at scale. While you can manage namespace labels in Git yourself, Plural's Global Services feature ensures these configurations are applied consistently across your entire fleet, preventing drift. This means you can define your Pod Security Standards policy once and have Plural automatically propagate it to hundreds of clusters. Furthermore, Plural's unified dashboard gives you a single place to monitor compliance and audit configurations, which is something a standard GitOps tool does not provide out of the box.