Pod security policy (PSP) removal FAQ

PodSecurityPolicy is a built-in admission controller that allows a cluster administrator to control security-sensitive aspects of pod specification. If a pod meets the requirements of its PSP, the pod is admitted to the cluster as usual. If a pod doesn’t meet the PSP requirements, the pod is rejected and can’t run.

This is an upstream change in the Kubernetes project, and not a change made in Amazon EKS. PSP was deprecated in Kubernetes 1.21 and removed in Kubernetes 1.25. The Kubernetes community identified serious usability problems with PSP. These included accidentally granting broader permissions than intended and difficulty in inspecting which PSPs apply in a given situation. These issues couldn’t be addressed without making breaking changes. This is the primary reason why the Kubernetes community decided to remove PSP.

To check if you’re using PSPs in your cluster, you can run the following command:

kubectl get psp

To see the pods that the PSPs in your cluster are impacting, run the following command. This command outputs the pod name, namespace, and PSPs:

kubectl get pod -A -o jsonpath='{range.items[?(@.metadata.annotations.kubernetes\.io/psp)]}{.metadata.name}{"\t"}{.metadata.namespace}{"\t"}{.metadata.annotations.kubernetes\.io/psp}{"\n"}'

Before upgrading your cluster to 1.25, you must migrate your PSPs to either one of these alternatives:

In response to the PSP deprecation and the ongoing need to control pod security from the start, the Kubernetes community created a built-in solution with (PSS) and Pod Security Admission (PSA). The PSA webhook implements the controls that are defined in the PSS.

You can review best practices for migrating PSPs to the built-in PSS in the EKS Best Practices Guide. We also recommend reviewing our blog on Implementing Pod Security Standards in Amazon EKS. Additional references include Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller and Mapping PodSecurityPolicies to Pod Security Standards.

Policy-as-code solutions provide guardrails to guide cluster users and prevents unwanted behaviors through prescribed automated controls. Policy-as-code solutions typically use Kubernetes Dynamic Admission Controllers to intercept the Kubernetes API server request flow using a webhook call. Policy-as-code solutions mutate and validate request payloads based on policies written and stored as code.

There are several open source policy-as-code solutions available for Kubernetes. To review best practices for migrating PSPs to a policy-as-code solution, see the Policy-as-code section of the Pod Security page on GitHub.

Amazon EKS clusters with Kubernetes version 1.13 or higher have a default PSP that’s named eks.privileged. This policy is created in 1.24 and earlier clusters. It isn't used in 1.25 and later clusters. Amazon EKS automatically migrates this PSP to a PSS-based enforcement. No action is needed on your part.

No. Besides eks.privileged, which is a PSP created by Amazon EKS, no changes are made to other PSPs in your cluster when you upgrade to 1.25.

No. Amazon EKS won't prevent a cluster update to version 1.25 if you didn't migrate off of PSP yet.

When a cluster that contains a PSP is upgraded to Kubernetes version 1.25, the API server doesn’t recognize the PSP resource in 1.25. This might result in pods getting incorrect security scopes. For an exhaustive list of implications, see Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller.

We don't expect any specific impact to Windows workloads. PodSecurityContext has a field called windowsOptions in the PodSpec v1 API for Windows pods. This uses PSS in Kubernetes 1.25. For more information and best practices about enforcing PSS for Windows workloads, see the EKS Best Practices Guide and Kubernetes documentation.