Kubernetes v1.25: Pod Security Becomes the New Norm

The release of Kubernetes v1.25 marks a significant milestone for pod security controls: the Pod Security Admission Controller (PSA) has reached “stable” status, while the Pod Security Policy (PSP) has been removed. PSP was deprecated in Kubernetes v1.21 and no longer functions in Kubernetes v1.25 and beyond.

The Pod Security Admission Controller replaces the Pod Security Policy and simplifies the enforcement of predefined Pod Security Standards by simply adding a label to a namespace. The Pod Security Standards are maintained by the K8s community, meaning you automatically receive updated security policies when new security-related features are introduced in Kubernetes.

What Changes Specifically for Developers/DevOps Teams?

With the stabilization of the Pod Security Admission Controller, managing pod security becomes easier and more effective. Developers and DevOps teams no longer have to deal with the now-obsolete PSP. Instead, they can focus on the new, more user-friendly security policies that provide better control over how pods are run within their clusters.

Practical Examples or Use Cases

Improved Violation Messages

Violation messages have been improved, so you now receive fewer duplicate messages. Instead of a complex error message when both the baseline and restricted policies check the same capability, you now see a simplified message:

pods "admin-pod" is forbidden: violates PodSecurity "restricted:latest": unrestricted capabilities (container "admin" must not include "SYS_ADMIN" in securityContext.capabilities.add)

Enhanced Namespace Warnings

When you change the enforce Pod Security labels in a namespace, the Pod Security Admission Controller checks all existing pods for violations and displays a warning if there are discrepancies. These warnings are now aggregated for pods with identical violations, making large namespaces with many replicas much clearer. An 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, you receive a warning if you apply a non-privileged label to a namespace that is exempt from enforcement:

Warning: namespace 'kube-system' is exempt from Pod Security, and the policy (enforce=baseline:latest) will be ignored

Changes to the Pod Security Standards

The Pod Security Standards enforced by the Pod Security Admission have been updated with support for the new Pod OS field. In v1.25 and later, certain Linux-specific constraints are no longer required when you explicitly set the .spec.os.name field of the pod to windows:

• Seccomp - The seccompProfile.type field for pod and container security contexts
• Privilege Escalation - The allowPrivilegeEscalation field on container security contexts
• Capabilities - The requirement to drop all capabilities in the capabilities field on containers

In Kubernetes v1.23 and earlier, the Kubelet did not enforce the Pod OS field. If your cluster includes nodes with a Kubelet version v1.23 or older, you should set the Restricted policies to a version prior to v1.25.

Collaborating with partners like ayedo can help you get the best support in implementing these new security standards and securing your Kubernetes environment.

Source: Kubernetes Blog