Introduction

Checking whether Pod Security Policy, usually shortened to PSP, is enabled depends first on the Kubernetes version you are running. PSP was deprecated in Kubernetes 1.21 and removed in Kubernetes 1.25, so on newer clusters the right answer is often that PSP cannot be enabled at all because the feature no longer exists.

First Check the Cluster Version

Start by checking the server version:

kubectl version --short

If the API server version is 1.25 or newer, Pod Security Policy is gone. In that case, you should look at Pod Security Admission or another policy system instead of hunting for PSP settings.

If the cluster is older, continue with the checks below.

Check Whether the PSP Resource Exists

If PSP is available in the cluster, you should be able to list the resource type.

kubectl api-resources | grep -i podsecuritypolicy

Or list policies directly:

kubectl get psp

If the resource type does not exist, either PSP is not available in this cluster version or the API is not enabled.

If kubectl get psp returns policies, that tells you the resource exists, but it still does not prove enforcement is active. You also need the admission plugin.

Check the Admission Plugin

For PSP to be enforced on older clusters, the API server must have the PodSecurityPolicy admission plugin enabled. On self-managed control planes, that is usually configured through the API server flags.

The flag looks like this conceptually:

--enable-admission-plugins=...,PodSecurityPolicy,...

How you inspect it depends on the environment:

• on self-managed clusters, inspect the API server manifest or startup flags
• on managed clusters, consult the provider configuration because direct control-plane access may not be available

On kubeadm-style clusters, a common place to check is the static pod manifest:

grep enable-admission-plugins /etc/kubernetes/manifests/kube-apiserver.yaml

If PodSecurityPolicy is not in that list, PSP is not being enforced even if PSP objects exist.

Check RBAC Bindings Too

PSP enforcement also depends on authorization. A user or service account must be allowed to use a specific policy. That usually means there is a Role, ClusterRole, RoleBinding, or ClusterRoleBinding connecting identities to the PSP.

For example:

kubectl get clusterrole,clusterrolebinding | grep -i psp

If policies exist and the admission plugin is on, but no one is authorized to use them, workloads may still fail or behave unexpectedly. So a practical PSP check has three layers:

• does the resource exist
• is the admission plugin enabled
• are the relevant identities bound to a policy

A Practical Interpretation Matrix

Use the results together rather than relying on one command:

• Kubernetes 1.25+: PSP is removed, so it is not enabled
• PSP resource missing on older cluster: PSP is not available or not enabled
• PSP resource present but admission plugin absent: policies exist but are not enforced as PSP admission
• PSP resource present and admission plugin enabled: PSP is active in principle
• PSP active but RBAC missing: enforcement exists, but workloads may not be authorized to use a policy

That is the distinction many quick answers skip.

Know the Modern Replacement

If you discover that PSP is unavailable because the cluster is new, the likely replacement is Pod Security Admission with namespace labels such as pod-security.kubernetes.io/enforce. That is a different mechanism and should not be confused with PSP checks.

In other words, if your cluster is modern, do not spend time trying to "turn PSP back on." The operational path is migration, not re-enablement.

Common Pitfalls

• Assuming kubectl get psp alone proves PSP is enforced is incorrect because the admission plugin may still be disabled.
• Forgetting the Kubernetes version check leads to wasted effort on clusters where PSP has already been removed.
• Seeing PSP objects in the API and assuming workloads can use them ignores the RBAC layer that authorizes policy use.
• Looking only at workload failures without checking admission configuration can make a PSP issue look like a generic deployment problem.
• Confusing Pod Security Admission with Pod Security Policy causes mixed guidance because they are related but different mechanisms.

Summary

• Start with the cluster version because PSP was removed in Kubernetes 1.25.
• On older clusters, check both the PSP resource and the PodSecurityPolicy admission plugin.
• Confirm RBAC bindings if you need to know whether workloads can actually use a policy.
• Treat the presence of PSP objects as only one part of the answer, not the whole answer.
• On newer clusters, investigate Pod Security Admission instead of PSP.