Rancher’s Pod Security Policy (PSP) feature is being deprecated in Kubernetes, and you need to migrate to the built-in Pod Security Admission (PSA) standards.
Let’s see what this looks like in practice. Imagine you have a restricted policy applied to a namespace. This is the equivalent of a restricted PSA.
apiVersion: v1
kind: Namespace
metadata:
name: restricted-ns
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/audit: restricted
When you try to create a pod that violates the restricted PSA, like one that runs as root, the admission controller rejects it.
kubectl run --namespace restricted-ns nginx --image=nginx
Error from server: admission webhook "pod-security-webhook.kubernetes.io" denied the request: [restricted] container "nginx" must not run as root (container "nginx" is running as root)
This is PSA in action. The pod-security.kubernetes.io/enforce label on the namespace dictates the policy that is enforced. restricted is the strictest, followed by balanced, and then privileged which allows almost anything.
The core problem PSA solves is providing a standardized, built-in way to enforce security best practices for pods, replacing the complexity and eventual removal of PSPs. Internally, PSA is a mutating and validating admission webhook that’s part of the Kubernetes API server itself. It doesn’t require separate installation or management like PSPs did.
When a pod is created, the API server intercepts the request. It checks the labels on the target namespace. If pod-security.kubernetes.io/enforce is set, it runs the pod’s security context against the rules defined for that policy level (privileged, baseline, restricted). If the pod violates the enforced policy, the API server rejects the creation request. The warn label will log warnings about violations without blocking creation, and audit will log violations for later review.
You control PSA by setting these labels on namespaces. You can choose to enforce, warn, or audit at different levels. For example, you might enforce: balanced on most namespaces but enforce: restricted on sensitive ones.
The most surprising true thing about Pod Security Admission is that it’s not a single monolithic policy, but rather a set of predefined profiles (privileged, baseline, restricted) that you apply at the namespace level. You don’t write custom policies like you did with PSPs; you select and apply these built-in profiles. This simplifies management but also means you have less granular control than PSPs offered.
The baseline profile is designed to prevent known privilege escalations. It’s less restrictive than restricted but still enforces important security measures. For instance, it disallows running as root, using hostNetwork, and running privileged containers, but it might permit capabilities like NET_RAW which restricted would deny.
When migrating from Rancher PSPs, you’ll need to map your existing PSP configurations to these PSA profiles. This often involves analyzing your current PSPs to understand what security measures they enforce and then choosing the PSA profile that best matches. For custom PSPs that don’t align neatly with the built-in profiles, you might need to consider using a third-party admission controller like OPA Gatekeeper or Kyverno.
The next step after understanding PSA is exploring how to manage these policies at scale using tools like GitOps, where namespace labels can be declaratively managed and applied to your cluster.