SecurityContext not available for the Internal sourceType any more

[Daniel Cihak]

Hi all,

We are using OpenShift together with our EAP operator installed by the Operator Lifecycle Manager. During our regular testing process where we install our operator on the OpenShift 4.14 we started to face an issue during the EAP operator installation related to the new pod security standards introduced in the OCP 4.14 version.
In the CatalogSource yaml there was an error:

couldn't ensure registry server - error ensuring pod: : error creating new
pod: eap-operator-: pods "eap-operator-hclxd" 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")

Looking into the code of the Operator Lifecycle Manager I found a constructor for the Pod object with a condition calling addSecurityContext method only in case grpcPoGrpcPodConfigdConfig and GrpcPodConfig.SecurityContextConfig is configured.

This implied modification of our CatalogSource configuration to include grpcPodConfig with a grpc sourceType and image:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
name: eap-operator
spec:
configMap: eap-operator
displayName: EAP Operator (QE)
publisher: Red Hat
sourceType: grpc
image: registry.redhat.io/redhat/redhat-operator-index:v4.13
grpcPodConfig:
securityContextConfig: restricted

(sourceType Internal was replaced by grpc and other configuration was added)

We need to use the image attribute with the operator index which has only stable channel for the EAP package. This blocks us from testing the unreleased operator version currently.

My question is, is there a possibility for the new pod security standards and SecurityContext in particular to be available also for the Internal sourceType so that we could keep our configuraion as it is or is it technically impossible?

Thanks for any help.

Daniel

[Anik Bhattacharjee]

Hey Daniel, 

Is there anything preventing you from building a test catalog image with just your unreleased operator in it for testing? 

Ref https://olm.operatorframework.io/docs/tasks/creating-a-catalog/ for more information. 

Any feature addition to and for the Internal source type is unlikely at this moment, unless there's a mission critical reason to have a discussion about it. 

 

Anik Bhattacharjee

Senior Software Engineer - Openshift

Red Hat

300 A Street

Boston, MA 02210

--
You received this message because you are subscribed to the Google Groups "Operator Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to operator-framew...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/dda838a5-7590-42ab-8bc6-c4e2388973e1n%40googlegroups.com.