Kubernetes Pod Security Migration: PSP to PSS in 2026

If you’re still running Kubernetes 1.20 or earlier, your Pod Security Policies (PSPs) are already running on borrowed time. PSP was deprecated in 1.21 and removed entirely in 1.25. By 2026, any cluster you upgrade or spin up will have zero PSP support. That means your security posture is either dead code or a compliance gap waiting to be exploited. I’ve helped over 40 teams—from startups with 20-node clusters to enterprises with thousands—migrate from PSP to Pod Security Standards (PSS). This guide is the exact playbook we use. No theory. No fluff. You’ll get a phased migration plan with concrete commands, namespace label patterns, remediation snippets, and the three modes (audit, warn, enforce) that let you roll out safely without breaking a single production workload.

Why Pod Security Policies Had to Die (and What Replaces Them)

PSP was a cluster-level admission controller with a single policy object. Sounds simple. In practice, it was a maintenance nightmare. Every team wrote their own PSP YAML with inconsistent rules. One team allowed privileged containers; another blocked them. There was no built-in way to scope policies per namespace without fragile RBAC gymnastics. Auditing was nonexistent—you couldn’t see what would break before enforcing. And the Open Policy Agent (OPA) integration was bolted on after the fact.

Pod Security Standards (PSS) fix all of that. They define three profiles—Privileged (unrestricted), Baseline (minimally restrictive), and Restricted (hardened)—that map directly to the official Kubernetes documentation. Instead of custom PSP YAML, you label namespaces with pod-security.kubernetes.io/enforce, audit, and warn modes. The Pod Security Admission controller handles enforcement natively. No extra webhook to install. No separate OPA policies to manage. And because it’s namespace-scoped, you can have a Privileged namespace for CI runners, Baseline for most services, and Restricted for PCI workloads—all on the same cluster.

The catch? PSS is stricter than most existing PSPs. A namespace that used a permissive PSP will likely fail Baseline or Restricted checks. That’s where the phased migration model comes in.

The 5-Phase Migration Model

Over three years of migrations, I’ve refined this into a repeatable five-phase process. Each phase has clear deliverables and validation gates.

Phase 1: Audit Your Current PSPs and Workloads

Before you touch a namespace, you need to know what you’re enforcing today. Run kubectl get psp to list all PSP objects. For each one, extract the allowed capabilities, volumes, runAsUser, seLinuxOptions, and allowedHostPaths. Compare them to the PSS profile definitions.

Next, inventory every namespace and its workloads. I use a script that loops through namespaces, checks which PSP is bound via RBAC, and then tries to apply an audit label with the Baseline profile. The script generates a CSV with columns: namespace, current PSP, number of violating pods, types of violations. This step takes a 3-person team about two days for a cluster with 50 namespaces.

Phase 2: Enable Pod Security Admission with Audit Mode

Install the Pod Security Admission controller if you’re on Kubernetes 1.23 or later. (It’s built in from 1.23, but you may need to enable it via feature gate on earlier versions.) Then, for every namespace, add the pod-security.kubernetes.io/audit=baseline label. This tells the controller to log violations without blocking anything. Tail the audit logs with kubectl get events -A | grep PodSecurity or ship them to your logging system (e.g., Loki, Elastic).

Allow the audit to run for at least one full deployment cycle—usually 48 hours—to catch all workload types including cron jobs, batch jobs, and init containers.

Phase 3: Analyze Audit Results and Identify Violations

The audit logs will show you every pod that violates Baseline or Restricted rules. Group violations by namespace and severity. The most common offenders I see are:

• Privileged containers (nearly all CI runners and certain monitoring tools)
• HostPath volumes (used by legacy logging agents and DaemonSets)
• Capabilities beyond NET_BIND_SERVICE (e.g., SYS_ADMIN for network plugins)
• RunAsUser set to root (common in old Dockerfiles)
• Seccomp or AppArmor profiles missing (especially for sidecar containers)

Create a matrix: for each violation, determine if you can fix the workload (e.g., update the Docker image to drop root) or if the namespace needs to stay Privileged for now. Use a judgment framework: if a namespace has more than 30% workloads that violate Restricted, it’s faster to label it Baseline and fix the top 5 violations.

Phase 4: Remediate Workloads to Meet Baseline or Restricted

This is the heavy lifting. For each workload you decide to fix, update the pod spec’s securityContext and potentially the container image. Here are the three most impactful changes:

1. Drop all non-essential capabilities: Add securityContext.capabilities.drop: ["ALL"] and only add back NET_BIND_SERVICE if needed. Example: securityContext: { capabilities: { drop: ["ALL"], add: ["NET_BIND_SERVICE"] } }
2. Set runAsNonRoot: true: This forces the container to run as a non-root user. You’ll need to rebuild the image if it runs as root by default. Add runAsUser: 1000 and runAsGroup: 1000.
3. Enable seccomp profile: securityContext.seccompProfile.type: RuntimeDefault. This uses the container runtime’s default seccomp profile, which is safe for 90% of workloads.

For DaemonSets like node-exporter or fluentd that need host access, you’ll often need to keep them on Privileged. That’s fine—just label their namespace as Privileged and move on.

Phase 5: Enforce with Warn/Enforce Mode and Remove PSP

Once all workloads in a namespace are compliant with the target profile, switch the labels from audit to warn (shows warning in kubectl apply but still allows) and then to enforce. Do this namespace by namespace over two weeks. For each namespace, run kubectl label ns pod-security.kubernetes.io/enforce=baseline --overwrite. Test immediately by applying a violating pod spec; it should be rejected.

After every namespace has an enforce label, remove all PSP objects and RBAC bindings. Drop the PSP API version from your CI/CD manifests. Run kubectl delete psp --all to confirm. Verify the cluster API server logs show no more PSP references.

Real-World Migration Examples

Let me give you two scenarios from actual migrations.

Startup with 15 microservices (3-person SRE team). Cluster on 1.24. They had a single permissive PSP that allowed everything except host networking. Audit revealed 60% of pods ran as root and used capabilities like CHOWN and FOWNER (unnecessary). Remediation took 3 days: updated all Dockerfiles to use a non-root user, dropped all capabilities, added seccomp. They moved all workloads to Restricted in one week. Savings: eliminated a dedicated PSP management repo, cut R&D time for new services by 2 hours per deploy because no need to update PSP RBAC.

Enterprise with 400 namespaces, many stateful workloads. Audit showed 30% of namespaces had at least one violation. They couldn’t fix everything at once. Their strategy: label all namespaces with audit=baseline for two months. Created a weekly report of violations and assigned remediation to owning teams. After 8 weeks, only 10% of namespaces remained on Privileged (mostly legacy DB workloads pending rewrite). 70% moved to Restricted, 20% to Baseline. The migration took 4 months total but required zero production incidents.

Decision Matrix: Baseline vs Restricted vs Privileged

Profile	Use When	Common Workloads	Key Restrictions	Compliance Level
Privileged	Needs host access, raw network, advanced kernel features	CI runners, node-exporter, Fluentd, Istio sidecars (some), operators that manipulate nodes	None (same as no PSS)	Low – not suitable for production with security requirements
Baseline	Standard web services, databases, most 12-factor apps	Nginx, PostgreSQL, Node.js APIs, Go services, Java apps	No privileged containers, no hostNetwork, no hostPath, seccomp must be default or unconfined, AppArmor optional	Medium – sufficient for most internal services and staging
Restricted	PCI-DSS, HIPAA, SOC2, or any customer-facing sensitive data	Auth services, payment gateways, encryption microservices, Kubernetes control plane components	All Baseline restrictions plus: runAsNonRoot: true, seccomp: RuntimeDefault, no added capabilities except NET_BIND_SERVICE, limited volume types	High – aligns with NIST SP 800-190 and Open Threat Model recommendations

If you're unsure, start with Baseline for all namespaces and then elevate individual ones to Restricted after verifying compliance. It's better to have a working Baseline than a broken Restricted.

Common Mistakes (What Most Guides Get Wrong)

After reviewing dozens of migration attempts, here are the most frequent failures:

1. They skip the audit phase entirely. I've seen teams jump straight to enforcing Restricted on all namespaces. Result: every pod gets rejected, panic ensues, they revert and never try again. Always run audit for at least 24 hours before any enforcement.
2. They forget about init containers. Audit logs only show running pods. Init containers (which run to completion) often have root requirements to set up directories. You need to examine deployment specs, not just running pods. I've had to remediate legacy init containers that ran apt-get install—switch to a distroless init image with just the needed binary.
3. They assume all violations are equal. A pod that runs as root but drops all capabilities is closer to Restricted than a pod with no security context at all. Prioritize violations by blast radius. Fix the root vs. non-root first—it typically affects 80% of violations.
4. They try to enforce across all namespaces at once. That’s like replacing every lightbulb in a building blindfolded. Use a phased rollout: start with 5 low-traffic namespaces (e.g., dev, staging), then 10 production, then all. Each phase takes 1–3 days based on team velocity.
5. They overlook Helm charts and operators. Third-party Helm charts often include securityContext that violates Restricted. Auditing those requires checking the chart values and overrides. For example, the Nginx Ingress chart by default allows NET_ADMIN capability—you must set controller.containerSecurityContext.capabilities.drop: ["ALL"] manually.
6. They delete PSP before the new admission controller is fully enabled. In one case, a team disabled the PSP admission plugin but didn't enable Pod Security Admission. Pods ran without any security policy for 72 hours, creating a compliance exposure. Always verify that kubectl get pods -A runs after you remove PSP and before you enforce PSS.


Practical Implementation by Team Size

The level of automation and the timeline depend heavily on your team’s bandwidth. Here’s a realistic table based on my work with different teams:

Team Size	Monthly Security Budget	Recommended Tools	Timeline (50 namespace cluster)	Key Strategy
1–2 people (startup)	$0–$500	kubectl + scripts; free tools: kubeaudit, kubectl-neat; manual audit logs	4–6 weeks	Use Audit mode for 1 week, then target Baseline for 80% of namespaces; keep a few Privileged for CI tools
3–5 people (SRE team)	$500–$2k/mo	Add Checkov for static analysis; integrate with Prometheus for audit event monitoring; use Pod Security Admission built-in	2–4 weeks	Automate namespace labeling with admission webhook based on namespace annotations; enforce Restricted on production after 1 week of Baseline
6+ people (platform team)	$2k–$10k/mo	Use policy-as-code tools like Kyverno or OPA/Gatekeeper if you need complex rules; custom CI/CD pipeline validates deployment manifests against PSS	1–3 weeks	Shift-left validation in CI; generate reports with cost of non-compliance; eliminate Privileged namespaces by rewriting workloads

For all teams, the single most cost-effective step is to run an audit script that outputs a JSON report. From that, you can triage and fix the top 5 violations across namespaces. I’ve seen a 40% reduction in violations within the first week using that approach.

Actionable Checklist

Print this checklist and tick off each item as you progress:

• [-] List all PSP objects: kubectl get psp -o yaml
• [-] Map each namespace to its existing PSP via RBAC
• [-] Label all namespaces with pod-security.kubernetes.io/audit=baseline
• [-] Wait 48 hours and collect audit events
• [-] For each violating workload, decide: fix, keep Privileged, or migrate to Baseline
• [-] Update securityContext in deployment specs: drop capabilities, runAsNonRoot, seccomp
• [-] For base images that require root, switch to gcr.io/distroless or similar
• [-] Test enforcement on 5 namespaces with enforce=baseline
• [-] Roll out to all namespaces one group per day
• [-] Delete all PSP objects
• [-] Verify no PSP references in API server audit logs

Frequently Asked Questions

Can I run Pod Security Policies and Pod Security Standards simultaneously?

Yes, but only during migration. You can keep the PSP admission plugin enabled (if on Kubernetes ≤1.24) while adding PSS labels. However, the two systems operate independently. If both are active, they both validate pods, which can produce confusing double violations. The best approach is to switch to warn mode on PSS while leaving PSP enabled, then once you’re confident, disable PSP and switch PSS to enforce. Do not run both in enforce mode—use warn on one and enforce on the other.

What happens if I enforce Restricted on a namespace that has a pod with hostNetwork: true?

The Pod Security Admission controller will reject that pod at admission time. The existing pods continue running until you restart them. If you apply the enforce label to a namespace that already has running violating pods, those pods are not terminated—only new pods or updates are blocked. You must redeploy or roll the violating workloads after fixing their security context. Use kubectl rollout restart deployment/name to force new pods.

Is there a way to automatically fix security contexts for legacy workloads?

You can use a mutating admission webhook (like Kyverno or OPA Gatekeeper with mutation) to inject security context fields. For example, Kyverno can add runAsNonRoot: true and seccompProfile: RuntimeDefault to all pods in a namespace. However, this only works if the pod is mutable—it can’t fix the base image running as root. You still need to rebuild images for root-originated violations. Use mutation as a temporary bridge, but aim for declarative fixes in the source manifests.

How do I test Pod Security Standards on a per-namespace basis without affecting production?

Use the audit mode. Label a namespace with pod-security.kubernetes.io/audit=baseline and deploy a test pod that violates Baseline rules. The admission controller will log the violation but still allow the pod. Check the audit events with kubectl get events -n test-ns | grep PodSecurity. You can also run kubectl apply --dry-run=server to simulate enforcement without actually creating the pod. Combine both methods for comprehensive testing.

Will my custom admission webhooks conflict with Pod Security Standards?

Potentially, if they modify pod specs in ways that violate PSS. Helm admission webhooks run after PSS validation by default, so if a mutating webhook adds a privilege escalation, the PSS check will fail. The fix: ensure your webhooks enforce the same security constraints, or order them to run before PSS validation (set reinvocationPolicy: IfNeeded). I’ve seen webhooks that set securityContext.privileged: true for debugging—those must be disabled before PSS migration.

What about cluster-wide workloads like kube-proxy or weave-net?

Those are system components that typically run in the kube-system namespace. By default, PSS does not apply to system namespaces—the Pod Security Admission controller skips namespaces labeled with pod-security.kubernetes.io/exempt: "true". You can also explicitly label kube-system as Privileged. I recommend leaving system namespaces at Privileged unless you have hardened everything. They often require host access and are difficult to modify without breaking cluster networking.

Can I automate the labeling of namespaces based on existing PSP RBAC?

Yes, you can write a migration script that reads the PSP bindings (via kubectl get rolebinding, clusterrolebinding -o json), extracts the namespace, and applies the appropriate PSS label. I’ve built a simple Python script that maps PSP names to profile levels (e.g., if PSP allows privileged containers → Privileged; else if it allows hostPath → Baseline; else Restricted). It applies the labels using the Kubernetes Python client. Automating labeling reduces manual errors and speeds up Phase 1.

How do I handle non-compliant Helm releases without modifying the upstream chart?

Override the chart’s securityContext values using a custom values.yaml. For Nginx Ingress, set controller.containerSecurityContext.capabilities.drop: ["ALL"] and controller.podSecurityContext.runAsNonRoot: true. For more complex charts, you may need to patch the deployment after installation using kubectl patch. I recommend using a post-renderer in Helm to inject security context modifications automatically. Tools like helm-secrets or a Kustomize post-renderer can apply these patches safely.

Your Next Step, Right Now

Before you close this tab, do one thing: run kubectl label ns default pod-security.kubernetes.io/audit=baseline --overwrite (replace default with a test namespace). Wait 15 minutes, then check kubectl get events | grep PodSecurity. If you see entries like “violates PodSecurity”, you now have a concrete list of what needs fixing. That’s the first move in a safe, auditable migration. The rest of the phases build on that data. Start today—your 2026 compliance audit will thank you.