Pod security policy (PSP) removal FAQ
PodSecurityPolicy
was deprecated in Kubernetes1.21
1.25
. If you are using PodSecurityPolicy in your
cluster, then you must migrate to the built-in Kubernetes
Pod Security Standards (PSS) or to a policy-as-code solution before upgrading
your cluster to version 1.25
to avoid interruptions to your workloads.
Select any frequently asked question to learn more.
PodSecurityPolicy
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:
Kubernetes PSS.
Policy-as-code solutions from the Kubernetes environment.
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)
You can review best practices for migrating PSPs to the built-in
PSS in the EKS Best Practices Guide
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
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
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