Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blog post about Pod Security admission graduating to stable #35614

Merged
merged 3 commits into from
Aug 25, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
90 changes: 90 additions & 0 deletions content/en/blog/_posts/2022-08-25-pod-security/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,90 @@
---
layout: blog
title: "Pod Security Admission goes Stable"
date: 2022-08-25
slug: pod-security-admission-stable
canonicalUrl: https://kubernetes.dev/blog/2022/08/25/pod-security-admission-stable/
---

**Authors:** Tim Allclair and 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 has been deprecated since Kubernetes v1.21](https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/),
but as of v1.25 it will no longer be functional.

Pod Security Admission was designed as PSP's replacement, and makes 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 when new K8s features are
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
community, which means you automatically get updated security policies when new K8s features are
community, which means you automatically get updated security policies when new features are

I'm a little confused here - whenever new features are introduced? Or when new features are introduced that might impact a security baseline?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Howe's this?

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.

introduced.


## What’s new since Beta?

Pod Security Admission hasn’t changed much since Beta (in Kubernetes v1.23). The focus has been on
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Pod Security Admission hasn’t changed much since Beta (in Kubernetes v1.23). The focus has been on
PodSecurity hasn’t changed much since the Beta in Kubernetes v1.23. The focus has been on

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feature doesn't have a super well-defined name. PodSecurity is the feature gate, but that's not really user-facing. Our main documentation page (https://kubernetes.io/docs/concepts/security/pod-security-admission/) mostly refers to it as "Pod Security Admission" (capitalization of Admission is optional), so I'd prefer to stick to that convention.

improving the user experience, while continuing to maintain a high quality and scalability bar.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"scalability bar" is not clear to me. "Ensuring performance at scale" perhaps?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just dropped it, as I think it's encapsulated by "high quality bar"


**Improved violation messages:**

Minor improvements to violation messages were made to produce
[fewer duplicate messages](https://github.com/kubernetes/kubernetes/pull/107698), so instead of
getting this (since the baseline & restricted policies have overlapping capabilities checks):

```
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:

```
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 modifying the `enforce` Pod Security labels on a namespace, PSA checks all existing pods for
violations and surfaces warning if any are out of compliance. Now,
[warnings are 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 applying a non-privileged 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:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Additionally, when applying a non-privileged 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:
Additionally, when you deploy a non-privileged Pod to a namespace that you
[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:

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This applies to the action of labeling a namespace (the word label was missing). How about:

Suggested change
Additionally, when applying a non-privileged 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:
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:

I prefer has been configured ... to you configured ... since the configuration may have been applied by someone else (e.g. GKE cluster provisioning).


```
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 are enforced by Pod Security admission, have been updated with support for the new Pod OS
field. For restricted profiles in versions v1.25 and up, the following linux-specific fields will no
longer be required when the pod's `.spec.os.name` has been explicitly set to `windows`:

* Seccomp - The `seccompProfile.type` field on pod and/or container security contexts
* Privilege escalation - The `allowPrivilegeEscalation` field on container security contexts
* Capabilities - The requirement to drop `ALL` capabilities

_Note that Kubelets prior to Kubernetes v1.24 did not enforce the Pod OS field, so clusters running
older nodes should explicitly
[pin restricted policies to a version](https://kubernetes.io/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-for-namespaces)
prior to v1.25._
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
_Note that Kubelets prior to Kubernetes v1.24 did not enforce the Pod OS field, so clusters running
older nodes should explicitly
[pin restricted policies to a version](https://kubernetes.io/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-for-namespaces)
prior to v1.25._
In Kubernetes v1.24 and earlier, the kubelet didn't enforce the Pod OS field. If your cluster runs nodes with
earlier version, 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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Went with:

Suggested change
_Note that Kubelets prior to Kubernetes v1.24 did not enforce the Pod OS field, so clusters running
older nodes should explicitly
[pin restricted policies to a version](https://kubernetes.io/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-for-namespaces)
prior to v1.25._
In Kubernetes v1.23 and earlier, the kubelet didn't enforce the Pod OS field. If your cluster runs
nodes with any of those versions, 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 Pod Security Policy to Pod Security Admission

A [guide](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/) was published
to make the process of migrating from PSP to PSA easier, and to help you choose the best migration
strategy for your use case. In addition, a tool called
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
A [guide](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/) was published
to make the process of migrating from PSP to PSA easier, and to help you choose the best migration
strategy for your use case. In addition, a tool called
For instructions to migrate from PodSecurityPolicy to the PodSecurity 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) is being developed to automate parts
of the migration process. We'll be talking about PSP migration in more detail at our upcoming
Kubecon talk,
[Migrating from Pod Security Policy](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/program/schedule/).