📢 Pod Security Standards enforcement might affect your solutions

297 views

Skip to first unread message

Camila Macedo

unread,

Jul 18, 2022, 5:53:59 AM7/18/22

to Operator Framework

Hi All,

Kubernetes API has been changing, and the PodSecurityPolicy[0] 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)[1], allowing cluster admins to enforce the Pod Security Standards with Namespace Labels[2].

💁What does it mean?

With the introduction of Pod Security Admission, Namespace and Pod/Containers can be defined with three different policies: Privileged, Baseline and Restricted. (More info[3]). Therefore, Pods/Containers 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[4]). 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[5] policy. However, If your solutions require escalated permissions then, you can ensure the namespace containing your solution is labeled[2] 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[6] 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)[7].