Pod Security Policy Deprecated: Migration, Alternatives & Best Practices

Key Takeaways

• Kubernetes deprecated PodSecurityPolicy in v1.21 and fully removed it in v1.25, forcing teams to replace it or risk losing pod-level security enforcement during upgrades.
  
• PSP was removed mainly because it was difficult to manage at scale, had confusing RBAC bindings, lacked audit or dry-run modes, and behaved inconsistently across clusters.
  
• Kubernetes replaced PSP with Pod Security Admission and Pod Security Standards, which apply simpler, namespace-level security profiles (Privileged, Baseline, Restricted).
  
• Migrating safely requires auditing existing PSP rules, mapping them to Pod Security Standards, and rolling out enforcement gradually using audit and warn modes to avoid breaking workloads.
  
• Admission policies protect clusters at deploy time, but teams still need runtime visibility to detect privilege escalation, misconfigurations, or suspicious container behavior after workloads start running.

Kubernetes security has evolved significantly over the past few releases. Due to the announcement that pod security policy was deprecated in Kubernetes 1.21 and fully removed in 1.25, many organizations were forced to rethink how they enforce Kubernetes pod security controls.

According to the 2025 CNCF Annual Cloud Native Survey, 82% of organizations running containers now use Kubernetes in production. As adoption continues to expand across industries, consistent pod-level security enforcement becomes increasingly critical. As the clusters scale and workloads diversify, relying on outdated security controls significantly increases the risk of privilege escalation, insecure security context configurations, and misconfigured Kubernetes resources.

What Pod Security Policy Deprecated Means in Kubernetes 1.21–1.25

When Kubernetes announced pod security policy deprecation in version 1.21, it signaled that the feature would eventually be removed. In Kubernetes 1.25, PodSecurityPolicy (PSP) was fully disabled and no longer available in the API.

Originally, a pod security policy acted as a cluster-level admission controller that validated pods against defined security constraints before they were admitted.

Once PSP was removed:

• Existing clusters upgrading to 1.25 lost PSP enforcement.
• The policy/v1beta1 API was eliminated for PodSecurityPolicy specifically. Note that other resources previously under policy/v1beta1, such as PodDisruptionBudget, were migrated to policy/v1 rather than removed.
• Clusters relying on PSP had to migrate to alternatives.
• Admission controller configuration had to be reworked.

If you did not proactively migrate before upgrading, your Kubernetes pod security posture could silently weaken.

Why Pod Security Policy Was Deprecated and Removed

Although the PSP was powerful, it had some architectural and operational limitations. Kubernetes maintainers documented the reasoning in the official Kubernetes 1.25 release notes (kubernetes.io). The key issues included:

1. Complex configuration and poor usability.
2. Inconsistent enforcement behavior.
3. Limited extensibility.
4. Lack of clear security standards alignment.

PSP became difficult to manage in large environments where multiple namespaces required different privilege levels. Instead of patching the feature incrementally, Kubernetes introduced a simpler, standardized replacement: Pod Security Admission and Pod Security Standards.

Key Limitations That Led to Pod Security Policy Deprecation

The following table summarizes the major limitations that pushed PSP toward removal:

These limitations made Kubernetes security harder instead of easier, especially in regulated environments.

Security Risks After Pod Security Policy Deprecated

When pod security policy deprecated, clusters that upgraded without migration faced real security risks. These include:

• Privilege escalation via allowPrivilegeEscalation: true
• Containers running as root
• HostPath volume misuse
• Host networking exposure
• Misconfigured security context settings

Example of a risky pod spec:

apiVersion: v1
kind: Pod
metadata:
  name: insecure-pod
spec:
  containers:
    - name: nginx
      image: nginx
      securityContext:
        runAsUser: 0
        allowPrivilegeEscalation: true
      volumeMounts:
        - name: host
          mountPath: /host
  volumes:
    - name: host
      hostPath:
        path: /

Without proper enforcement, this configuration could expose the entire node filesystem.

What Replaced Pod Security Policy?

To address the shortcomings of PSP, Kubernetes introduced:

1. Pod Security Admission (PSA)
2. Pod Security Standards (PSS)

Pod Security Admission is a built-in admission controller that enforces predefined Pod Security Standards. Unlike PSP, PSA is:

• Namespace-scoped
• Declarative
• Easier to audit
• Simpler to reason about

Understanding Pod Security Standards After Pod Security Policy Deprecated

Pod Security Standards define three security profiles:

These are enforced using namespace labels:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: baseline

This enables multi-mode enforcement:

• Enforce
• Audit
• Warn

A significant improvement over PSP’s binary behavior.

Using OPA Gatekeeper and Kyverno After Pod Security Policy Deprecated

While Pod Security Admission covers standard security needs, some environments require advanced policy logic. Two popular alternatives are:

1. OPA Gatekeeper
2. Kyverno

OPA Gatekeeper enables custom policy enforcement using Rego:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-team-label
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    labels: ["team"]

Kyverno provides policy enforcement using Kubernetes-native YAML:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-root
spec:
  validationFailureAction: enforce
  rules:
    - name: no-root-user
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Running as root is not allowed"
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true

These tools allow fine-grained Kubernetes pod security enforcement beyond Pod Security Standards.

How to Migrate from Pod Security Policy

Migrating after pod security policy deprecated is not simply a matter of disabling PSP and enabling Pod Security Admission. A rushed migration can either break workloads or unintentionally weaken your Kubernetes pod security posture. A successful migration requires auditing, mapping, staged rollout, and continuous validation. Below is a structured approach that platform teams can follow:

Step 1: Audit Existing PSP Rules

The first step in any migration is understanding what your current PodSecurityPolicies are enforcing. Many organizations discover that PSPs were created years ago and never revisited.

Start by listing all PSP objects:

kubectl get psp

Then inspect each policy in detail:

kubectl describe psp <psp-name>

Pay close attention to:

• allowPrivilegeEscalation
• runAsUser and runAsNonRoot
• Allowed volume types (especially HostPath)
• Host networking, PID, and IPC settings
• Required security context fields
• Capability restrictions

It is equally important to identify how each PSP is bound using RBAC. The RBAC bindings that a PSP uses are relied on heavily when determining which user(s)/service account(s) are allowed to use which policies. If this relationship is not accounted for during the migration process, production workloads may fail unexpectedly.

Document all findings before proceeding. This becomes your migration baseline.

Step 2: Map PSP to Pod Security Admission Levels

Pod Security Admission does not give custom rule definitions like PSP used to provide. Instead, it enforces standardized Pod Security Standards: Privileged, Baseline, and Restricted. Most PSP configurations map naturally to either Baseline or Restricted. However, some granular PSP rules may not have direct equivalents.

For example:

• PSP enforcing runAsNonRoot aligns with Restricted.
• PSP preventing privilege escalation aligns with Baseline and Restricted.
• PSP allowing host networking aligns with Privileged.

Create an internal mapping matrix between:

• Existing PSP rules
• Corresponding Pod Security Standards
• Required namespace labels

If certain PSP rules do not map cleanly, you may need to supplement enforcement using OPA Gatekeeper or Kyverno. This shows that disabling PSP does not reduce security coverage.

Step 3: Test With Enforce, Audit, and Warn Modes

One of the major improvements over PSP is the ability to use multiple enforcement modes simultaneously. Instead of enforcing immediately, start with audit mode:

apiVersion: v1
kind: Namespace
metadata:
 name: staging
 labels:
   pod-security.kubernetes.io/audit: restricted

Audit mode logs violations without blocking workloads. This allows teams to observe which deployments would fail under strict enforcement.

You can also enable warn mode to surface warnings at deployment time. When a pod spec is submitted, warn mode returns a warning in the API response, visible in kubectl output or CI/CD pipeline logs. Note that this is not a shift-left mechanism but rather to catch violations earlier in development, you'll need a separate tool such as kubectl --dry-run, or a policy linter integrated into your CI pipeline.

Monitor:

• API server audit logs
• CI/CD pipeline feedback
• Deployment warnings

Once violations are addressed, transition to enforce mode gradually.

Step 4: Gradual Rollout Across Namespaces

Applying Restricted enforcement cluster-wide without testing can cause widespread deployment failures. Instead, roll out in controlled phases:

1. Development namespaces
2. Staging environments
3. Low-risk production workloads
4. Critical production namespaces

This staged approach reduces operational risk and gives teams time to remediate workloads that rely on elevated permissions.

For example:

metadata:
 labels:
   pod-security.kubernetes.io/enforce: restricted

Namespace-level enforcement also makes it easier to isolate legacy workloads that may temporarily require Baseline or Privileged profiles. Over time, aim to reduce the number of namespaces operating under less restrictive profiles.

Common Challenges When Pod Security Policy Is Deprecated

When PSP is removed, organizations often encounter operational and security challenges.

The biggest issue is visibility. Admission controllers validate at deploy time, not at runtime.

Best Practices After Pod Security Policy Deprecated in Kubernetes

After the pod security policy was deprecated, Kubernetes security must be intentional and layered. The following best practices help maintain a strong and consistent security posture across clusters:

• Default to Restricted Level for New Namespaces: The Restricted Pod Security Standard provides the strongest built-in safeguards against privilege escalation and insecure configurations. By setting this as the default for new namespaces, you ensure that workloads must explicitly justify elevated permissions rather than inheriting them unintentionally.
  
• Use Baseline Only When Necessary: The Baseline profile blocks known privilege escalation vectors but allows more flexibility than Restricted. It should be used only for workloads that genuinely require broader permissions. Overusing Baseline weakens the overall Kubernetes pod security posture.
  
• Avoid Privileged Unless Absolutely Required: The Privileged profile removes most security restrictions and should be reserved for system components or infrastructure-level workloads. Allowing general applications to run under Privileged significantly increases the attack surface and risk of container breakout.
  
• Regularly Audit Namespace Labels: Namespace labels control Pod Security Admission enforcement. Over time, configuration drift can occur due to manual changes or new deployments. Periodic audits ensure that namespace-level enforcement aligns with organizational security policies.
  
• Combine Admission Control With Runtime Detection: Admission controllers validate configuration at deployment time, but do not monitor runtime behavior. Combining Pod Security Admission with runtime observability ensures that suspicious actions, configuration drift, or privilege escalation attempts are detected after workloads start running.
  
• Monitor for Privilege Escalation Attempts: Even when admission policies are enforced, misconfigurations or new vulnerabilities can introduce risk. Monitoring runtime signals such as unexpected setuid calls, host namespace access, or elevated capabilities helps detect privilege escalation attempts before they cause damage.
  
• Automate Admission Controller Configuration via GitOps: Managing admission controller configuration as code improves consistency and traceability. Using GitOps workflows ensures that policy changes are reviewed, version-controlled, and automatically synchronized across clusters, reducing human error.

Security in Kubernetes must be layered and continuously validated. Admission controls provide a strong foundation, but ongoing monitoring and automation are essential to maintain resilience in dynamic environments.

Real-Time Kubernetes Security Visibility After Pod Security Policy Deprecated With groundcover

Admission controllers such as Pod Security Admission validate Kubernetes resources before deployment, ensuring that pod specifications comply with predefined security standards. However, configuration validation alone is not sufficient. Runtime behavior can still introduce security risks that admission controls cannot detect.

After pod security policy deprecated, organizations need runtime observability to identify potential security violations once workloads are running inside the cluster. This includes monitoring for:

• Privilege escalation attempts
• Suspicious or unexpected security context behavior
• HostPath volume misuse
• Unusual system call activity at the container level

This is where groundcover becomes valuable. It provides deep runtime visibility into Kubernetes environments using eBPF-based instrumentation, allowing security and platform teams to observe workload behavior without modifying applications or deploying sidecars.

Because groundcover operates using a BYOC (Bring Your Own Cloud) model, the observability stack runs directly inside your cloud infrastructure. This architecture helps organizations retain full control over telemetry while avoiding the need to send sensitive runtime data to external SaaS platforms.

Using groundcover’s Kubernetes observability platform, teams can gain detailed insight into how workloads behave after they pass admission control. By leveraging eBPF-based telemetry, groundcover collects runtime signals from the kernel layer with minimal overhead and no sidecar deployment. These capabilities enable teams to:

• Track security context violations across running containers
• Detect deviations from Pod Security Standards after deployment
• Correlate runtime events with Kubernetes deployment changes
• Observe container-level system call activity and privilege behavior

With its self-service signup model and free tier, organizations can deploy groundcover quickly inside their own cloud environment and begin monitoring Kubernetes workloads without complex infrastructure changes.

While Pod Security Admission enforces static security policies at deployment time, groundcover complements these controls by providing continuous runtime observability. This helps close the visibility gap between configuration-based security enforcement and real-world workload behavior inside Kubernetes clusters.

Conclusion

The removal of PodSecurityPolicy marks a significant architectural shift in Kubernetes security. While PSP offered granular controls, its complexity limited scalability and predictability in modern environments. Pod Security Admission and Pod Security Standards provide a more structured and standardized enforcement model. However, admission control alone is insufficient for complete Kubernetes security. Organizations must combine namespace-level enforcement, advanced policy engines where required, and runtime visibility mechanisms to maintain strong protection. As Kubernetes adoption continues to expand, layered security - spanning admission, policy enforcement, and runtime detection - is essential to ensure resilient and secure clusters.