Introduction

PodSecurityPolicy, or PSP, was the old Kubernetes mechanism for restricting what pods were allowed to do. The first important thing to know today is that PSP was deprecated long ago and removed from Kubernetes starting with version 1.25, so a modern kubeadm cluster cannot be configured to use PSP at all.

That means the right answer depends on cluster age. If you run a current kubeadm cluster, use Pod Security Admission instead. If you are maintaining an older pre-1.25 cluster, PSP can still be relevant as a legacy configuration.

On Modern kubeadm Clusters, Use Pod Security Admission

For current Kubernetes versions, the replacement for PSP is Pod Security Admission. Instead of creating PodSecurityPolicy objects and RBAC bindings for the use verb, you label namespaces with the desired policy level.

A simple restricted example looks like this:

1kubectl label namespace my-team \
2  pod-security.kubernetes.io/enforce=restricted \
3  pod-security.kubernetes.io/audit=restricted \
4  pod-security.kubernetes.io/warn=restricted

This is the path you should follow on a current kubeadm installation. Trying to enable PSP admission plugins on a version that no longer supports PSP will not work.

Historical PSP Setup On Older kubeadm Clusters

If you are operating an older cluster that still supports PSP, configuration had two major parts:

1. enable the PodSecurityPolicy admission plugin on the API server
2. create a PSP object and grant workloads permission to use it

On kubeadm-managed clusters, the API server manifest lives under /etc/kubernetes/manifests/kube-apiserver.yaml. Historically, enabling PSP meant adding PodSecurityPolicy to the --enable-admission-plugins list. Because kubeadm control-plane components are static pods, editing that manifest caused the kubelet to restart the API server automatically.

The policy object itself might look like this:

1apiVersion: policy/v1beta1
2kind: PodSecurityPolicy
3metadata:
4  name: restricted-policy
5spec:
6  privileged: false
7  allowPrivilegeEscalation: false
8  requiredDropCapabilities:
9    - ALL
10  runAsUser:
11    rule: MustRunAsNonRoot
12  seLinux:
13    rule: RunAsAny
14  fsGroup:
15    rule: RunAsAny
16  supplementalGroups:
17    rule: RunAsAny
18  volumes:
19    - configMap
20    - emptyDir
21    - projected
22    - secret
23    - downwardAPI
24    - persistentVolumeClaim

That policy denies privileged pods and requires a non-root user model, which is why PSP could be powerful but also operationally brittle.

PSP Required RBAC Too

Creating the PSP object was not enough. A subject also needed permission to use it through RBAC:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRole
3metadata:
4  name: use-restricted-psp
5rules:
6  - apiGroups: ["policy"]
7    resources: ["podsecuritypolicies"]
8    resourceNames: ["restricted-policy"]
9    verbs: ["use"]
10---
11apiVersion: rbac.authorization.k8s.io/v1
12kind: ClusterRoleBinding
13metadata:
14  name: use-restricted-psp-binding
15roleRef:
16  apiGroup: rbac.authorization.k8s.io
17  kind: ClusterRole
18  name: use-restricted-psp
19subjects:
20  - kind: Group
21    name: system:authenticated
22    apiGroup: rbac.authorization.k8s.io

In real clusters, you would usually bind a narrower service account or group, not everyone authenticated. This RBAC layer was one of the reasons PSP setups could become hard to reason about.

Why PSP Was Difficult To Operate

PSP combined admission logic with RBAC authorization, which made failure modes harder to diagnose. A pod could be rejected because the policy itself was too strict, because the namespace setup was incomplete, or because the service account had no permission to use the policy.

That complexity is a large part of why the feature was deprecated and ultimately removed. Pod Security Admission is simpler because policy choice is driven by namespace labels and standardized profiles rather than ad hoc policy objects plus use bindings.

Migrating Legacy Clusters

If you still operate a PSP-based kubeadm cluster, the practical migration path is:

• inventory existing PSP rules
• map them to Pod Security Standards where possible
• label namespaces for privileged, baseline, or restricted
• test workloads that previously relied on PSP exceptions

Not every custom PSP rule maps one-to-one to the newer model, so some clusters also need supplementary admission controls or policy engines such as Kyverno or OPA Gatekeeper.

Common Pitfalls

One common mistake is following an old PSP tutorial on a modern kubeadm cluster where PSP no longer exists. Another is assuming that creating a PSP object alone is enough, when legacy PSP also required matching RBAC use permissions. Operators also often underestimate migration work because Pod Security Admission is not a drop-in serialization of every old PSP rule. Finally, if you are truly on an old cluster, remember that legacy configuration examples usually target policy/v1beta1, which itself signals that you are dealing with an older Kubernetes era.

Summary

• PodSecurityPolicy was removed from Kubernetes starting in 1.25, so modern kubeadm clusters should use Pod Security Admission instead.
• On current clusters, label namespaces with Pod Security Admission levels such as restricted.
• On older legacy clusters, PSP required both an admission plugin and RBAC permission to use the policy.
• PSP was operationally complex because enforcement depended on both policy definition and authorization.
• If you still run PSP, plan a migration rather than expanding legacy dependence on it.