Pod Security Admissions

Kubernetes 1.24 removes the Pod Security Policy feature in favor of Pod Security Admission. This document explains the impact on APPUiO Cloud users.

TL;DR:

  • Check PSA warnings

  • Set security context accordingly in your workload resources.

Introduction

Up until OpenShift 4.10, OpenShift only had Security Context Constraints (SCCs). Since Kubernetes 1.3, Pod Security Policy (PSP) has been the built-in way to manage security-related Pod fields. However, it turned out that PSPs were too complex, so Kubernetes 1.21 deprecated and 1.24 completely dropped them in favor of Pod Security Admission (PSA).

PSA is a simpler approach, which is similar–but not identical–to OpenShift’s SCCs. Pod Security Admission was designed to meet the most common security needs out of the box while being simple to understand and adopt.

OpenShift 4.11

OpenShift 4.11 introduces PSA globally with restricted audit logging and API warnings, but it doesn’t replace SCC with PSA, instead running both mechanisms in parallel.

OpenShift 4.11 already enables PSA in auditing mode (including API warnings) and has additional logic which ensures that SCCs and PSAs don’t conflict. Since it runs PSA in warning mode, it leads to warnings like the following:

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "storage-bench" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "storage-bench" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "storage-bench" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "storage-bench" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

At the core of PSA, there are the Pod Security Standards, which define three different policies to broadly cover the security spectrum. These policies are cumulative and range from highly permissive to highly restrictive.

Privileged

Unrestricted policy, providing the widest possible level of permissions. This policy allows for known privilege escalations.

Baseline

Minimally restrictive policy which prevents known privilege escalations. Allows the default (minimally specified) Pod configuration.

Restricted

Heavily restricted policy, following current Pod hardening best practices.

On APPUiO Cloud, the default is baseline and can not be changed. If you need more security and do want to set restricted, please visit roadmap.appuio.cloud/ and let us know.

Under Pod Security Admission, the built-in Pod Security admission controller enforces the configured Pod Security Standards. Pod security restrictions are managed at the namespace level, and are processed when pods are created. The PSA admission controller will deny the creation of workloads (Pods, Deployments, etc.) if they don’t adhere to the configured Pod Security Standard of the namespace.

PSA and SCCs

On OpenShift, Pod Security Admission and Security Context Constraints run in parallel and OpenShift makes sure that PSA and SCCs are kept in sync.

The configuration for a namespace is kept in sync by setting the PSA labels according to the highest privileged SCC which is can be used in the namespace. This is handled by the Cluster Policy Controller.

Since this results in a PSA configuration that’s never more restrictive than SCCs, a pod allowed by an SCC will also be allowed by PSA. ` However, PSA will validate workloads before the SCC mutating webhook is applied. Therefore, if you leave Security Contexts for your workloads empty and rely on the SCC controller to inject sensible defaults, you will see warnings during deployment.

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != fa..

On OpenShift 4.11, these warnings won’t stop the Pod from running, as PSA is set to warn by default. However, it’s not documented whether this configuration will change in future Openshift 4 releases. To silence these warnings it’s required to explicitly set appropriate Security Contexts in workload manifests.

OpenShift 4.12

What’s planned for Openshift 4.12, coming December 2022?

  1. By the global Pod Security Admission configuration, all namespaces will run in the restricted enforcement mode. This Pod Security Admission (PSA) level aligns with the restricted-v2 SCC, so if your workload is categorized into restricted-v2, it will be able to run in a namespace that enforces the PSA as restricted.

  2. In cases where the workload has access to higher SCC privileges (via its Service Account,) OpenShift will label namespaces, via the new label synchronization component, to synchronize the PSA enforcement level in order to keep workloads running.

The primary recommendation at this point is to ensure any workload has the security context properly set. Therefore, the best path is to ensure the workloads can run with restricted permissions. When this is done, your product will run on restricted namespaces on vanilla Kubernetes and will have the best chance of running properly on any other Kubernetes distribution with any vendor within restricted namespaces. The application will also have access to the restricted-v2 on OpenShift and won’t be rejected by cluster administrators trying to enforce restrictions.