-
Bug
-
Resolution: Done
-
Critical
-
OP-2.3.4.GA
-
None
-
False
-
None
-
False
-
-
-
-
-
-
-
-
With OCP 4.11 and 4.12 we have been seeing warning like
Warning: would violate PodSecurity "restricted:v1.24": allowPrivilegeEscalation != false (container "wildfly-operator" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "wildfly-operator" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "wildfly-operator" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "wildfly-operator" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
With 4.13, (nightly builds) OpenShift started to enforce new standards and EAP operator fails to deploy. Both released 2.3 and not yet released 2.4 versions are affected.
Error:
E0201 14:02:59.946423 1 queueinformer_operator.go:298] sync {"update" "msimka-namespace/eap-operator"} failed: couldn't ensure registry server - error ensuring pod: : error creating new pod: eap-operator-: pods "eap-operator-b2t2n" is forbidden: violates PodSecurity "restricted:v1.24": allowPrivilegeEscalation != false (container "configmap-registry-server" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "configmap-registry-server" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "configmap-registry-server" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "configmap-registry-server" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
which can be found in OLM log
oc logs pod/catalog-operator-9d959f49d-2q8ml -n openshift-operator-lifecycle-manager
It was slightly discussed on GH issue
My understanding is the warning comes due to the standard pod security policies managed by the cluster or namespace where you are installing the Operator. We have to address them by defining the SecurityContext on the Deployment resource that deploys the Operator, we have to think about how we should do it and whether it will need to be dynamic or exposed to the user. I'm not sure yet.
With this PR the user will be able to configure the SecurityContext of the pods generated by the StatefulSet, so it will help the users to adapt the Operator workload to the current cluster policy if they need it.
Some resources:
- is caused by
-
AUTH-262 Pod Security Admission Integration - Restricted Enforcement
- In Progress
- is incorporated by
-
JBEAP-24635 EAP Operator 2.4.0 release
- Closed
- is related to
-
JBEAP-24968 Operator was not installed on OCP 4.14 due to the new pod security standards
- New
-
OCPBUGS-8710 [4.13] don't enforce PSa in 4.13
- Closed