kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

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
pull/36272/head
Tim Allclair 2022-08-25 01:10:06 -07:00 committed by GitHub
parent 77c7c5c06a
commit d795e02c3d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 94 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

94
content/en/blog/_posts/2022-08-25-pod-security/index.md Normal file
View File

@ -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.