📢 Pod Security Standards enforcement might affect your solutions

[camilamacedo86]

Kubernetes API has been changing, and the PodSecurityPolicy API is deprecated and will no longer be served from k8s 1.25. This API is replaced by a new built-in admission controller (KEP-2579: Pod Security Admission Control), allowing cluster admins to enforce the Pod Security Standards with Namespace Labels.

💁What does it mean?

With the introduction of the new built-in admission controller that enforces the Pod Security Standards, Namespace and Pods can be defined with three different policies: Privileged, Baseline and Restricted. Therefore, Pod(s) that are not configured according to the enforced security standards defined globally or on the namespace level will not be admitted and cannot run.

From k8s 1.25, namespaces will be labeled as "Privileged" by default. (More info). However, cluster admins may ask why escalated permissions are necessary and push for the workload definition to be changed so it can be qualified as restricted, thereby allowing the NS to be labeled as restricted. So, if your workload doesn’t meet the requirements, it will fail to run.

TL'DR:

By testing your Operator on k8s clusters >= 1.24 you will check warnings such as the following when you try to apply manifest which are not comply with the PodSecurity restricted policy (assuming that the namespace is labeled with pod-security.kubernetes.io/warn: restricted):

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

🚀 What is recommended ?

The best option for any new publication is to ensure that workloads (Operators, Operands) are configured to run under the restricted policy. However, If your solutions require escalated permissions then, you can ensure the namespace containing your solution is labeled accordingly. You can either update your operator to manage the namespace labels or include the namespace labelling as part of the manual install instructions.

⚠️ : If you develop solutions to be distributed/deployed on Openshift/OKD, such as by adding your Operator bundle into the RedHat Community repo then: please, ensure that you check the topic Pod Security Standards and Openshift changes on 4.11 and 4.12 that might affect your workloads(Operator, Operands).

👩‍🏭 Guidance with examples and helpers

💡 IMPORTANT: The most straightforward way to ensure your workloads can work on a restricted namespaces by labeling the namespaces where they should run by enforcing the restricted policy and verifying if they are admitted and are successfully running. It is recommended to ensure the desired behaviour via an e2e test

Please, ensure that you check the guide to see code examples, tips and helpers as further info.