From d795e02c3d67224b64235004e0de4d9e6aa1dd2f Mon Sep 17 00:00:00 2001 From: Tim Allclair Date: Thu, 25 Aug 2022 01:10:06 -0700 Subject: [PATCH] Blog post about Pod Security admission graduating to stable (#35614) * PSA staable blog post * Address feedback on Pod Security blog post * Address feedback on Pod Security blog post --- .../_posts/2022-08-25-pod-security/index.md | 94 +++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 content/en/blog/_posts/2022-08-25-pod-security/index.md diff --git a/content/en/blog/_posts/2022-08-25-pod-security/index.md b/content/en/blog/_posts/2022-08-25-pod-security/index.md new file mode 100644 index 00000000000..1f949ba778d --- /dev/null +++ b/content/en/blog/_posts/2022-08-25-pod-security/index.md @@ -0,0 +1,94 @@ +--- +layout: blog +title: "Kubernetes v1.25: Pod Security Admission Controller in Stable" +date: 2022-08-25 +slug: pod-security-admission-stable +--- + +**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](https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/), +and no longer functions in Kubernetes v1.25 and later. + +The Pod Security admission controller replaces PodSecurityPolicy, making it easier to enforce predefined +[Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-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. + + +## What’s new since Beta? + +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. + +### Improved violation messages + +We improved violation messages so that you get +[fewer duplicate messages](https://github.com/kubernetes/kubernetes/pull/107698). 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) +``` + +### Improved namespace warnings + +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](/blog/2020/09/03/warnings/) if any are out of compliance. These +[warnings are now aggregated](https://github.com/kubernetes/kubernetes/pull/105889) 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 been +[configured to be exempt](https://kubernetes.io/docs/concepts/security/pod-security-admission/#exemptions), +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 +``` + +### Changes to the Pod Security Standards + +The [Pod Security Standards](https://kubernetes.io/docs/concepts/security/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 `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 didn't enforce the Pod OS field. +If your cluster includes nodes running a v1.23 or older kubelet, you should explicitly +[pin Restricted policies](https://kubernetes.io/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-for-namespaces) +to a version prior to v1.25. + +## Migrating from PodSecurityPolicy to the Pod Security admission controller + +For instructions to migrate from PodSecurityPolicy to the Pod Security admission controller, and +for help choosing a migration strategy, refer to the +[migration guide](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/). +We're also developing a tool called +[pspmigrator](https://github.com/kubernetes-sigs/pspmigrator) to automate parts +of the migration process. + +We'll be talking about PSP migration in more detail at our upcoming KubeCon 2022 NA talk, +[*Migrating from Pod Security Policy*](https://sched.co/182Jx). Use the +[KubeCon NA schedule](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/program/schedule/) +to learn more.