Red Hat Product Security recommends that pods be deployed with readOnlyRootFilesystem set to true in the SecurityContext, but does not require it because a successful attack can only be carried out with a combination of weaknesses and OpenShift runs with a variety of mitigating controls. 

However, customers are increasingly asking questions about why pods from Red Hat, and deployed as part of OpenShift, do not follow common hardening recommendations. 

Note that setting readOnlyRootFilesystem to true ensures that the container's root filesystem is mounted as read-only. This setting has nothing to do with host access. 

For more information, see 
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

Setting the readOnlyRootFilesystem flag to true reduces the attack surface of your containers, preventing an attacker from manipulating the contents of your container and its root file system.

If your container needs to write temporary files, you can specify the ability to mount an emptyDir in the Security Context for your pod as described here. https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod 

The specific components we found in testing to need readOnlyRootFilesystem enabled are

https://github.com/openshift/multus-admission-controller
https://github.com/openshift/cluster-network-operator (specifically ovnkube-control-plane, network-node-identity)
https://github.com/openshift/cloud-network-config-controller