Authors: Tim Allclair (Google), Sam Stoelinga (Google)
The release of Kubernetes v1.25 marks a major milestone for Kubernetes out-of-the-box pod security controls: Pod Security admission (PSA) graduated to stable, and Pod Security Policy (PSP) has been removed.PSP was deprecated in Kubernetes v1.21, and no longer functions in Kubernetes v1.25 and later.
The Pod Security admission controller replaces PodSecurityPolicy, making it easier to enforce predefinedPod Security Standards by simply adding a label to a namespace. The Pod Security Standards are maintained by the K8s community, which means you automatically get updated security policies whenever new security-impacting Kubernetes features are introduced.
Pod Security Admission hasn’t changed much since the Beta in Kubernetes v1.23. The focus has been on improving the user experience, while continuing to maintain a high quality bar.
We improved violation messages so that you getfewer duplicate messages. For example, instead of the following message when the Baseline and Restricted policies check the same capability:
pods "admin-pod" is forbidden: violates PodSecurity "restricted:latest": non-default capabilities (container "admin" must not include "SYS_ADMIN" in securityContext.capabilities.add), unrestricted capabilities (container "admin" must not include "SYS_ADMIN" in securityContext.capabilities.add)
You get this message:
pods "admin-pod" is forbidden: violates PodSecurity "restricted:latest": unrestricted capabilities (container "admin" must not include "SYS_ADMIN" in securityContext.capabilities.add)
When you modify the
enforce Pod Security labels on a namespace, the Pod Security admission controller checks all existing pods for violations and surfaces a warning if any are out of compliance. Thesewarnings are now aggregated for pods with identical violations, making large namespaces with many replicas much more manageable. For example:
Warning: frontend-h23gf2: allowPrivilegeEscalation != false Warning: myjob-g342hj (and 6 other pods): host namespaces, allowPrivilegeEscalation != false Warning: backend-j23h42 (and 1 other pod): non-default capabilities, unrestricted capabilities
Additionally, when you apply a non-privileged label to a namespace that has beenconfigured to be exempt, you will now get a warning alerting you to this fact:
Warning: namespace 'kube-system' is exempt from Pod Security, and the policy (enforce=baseline:latest) will be ignored
The Pod Security Standards, which Pod Security admission enforces, have been updated with support for the new Pod OS field. In v1.25 and later, if you use the Restricted policy, the following Linux-specific restrictions will no longer be required if you explicitly set the pod's
.spec.os.name field to
- Seccomp - The
seccompProfile.typefield for Pod and container security contexts
- Privilege escalation - The
allowPrivilegeEscalationfield on container security contexts
- Capabilities - The requirement to drop
ALLcapabilities in the
capabilitiesfield on containers
In Kubernetes v1.23 and earlier, the kubelet didn't enforce the Pod OS field. If your cluster includes nodes running a v1.23 or older kubelet, you should explicitlypin Restricted policiesto a version prior to v1.25.
For instructions to migrate from PodSecurityPolicy to the Pod Security admission controller, and for help choosing a migration strategy, refer to themigration guide. We're also developing a tool calledpspmigrator to automate parts of the migration process.