The openshift-sriov-network-operator namespace is labelled with openshift.io/run-level: "1" From bug #1805488: Run-level 1 bypasses SCC, but many components have no need for that (are less secure as a result). Every component that does not need to be up before SCC starts should be in either the anyuid or restricted SCC profile so they get a stable SELinux label. Because these components are running without the appropriate restrictions, the security profile of these core components is weaker than it should be. All platform components that can run without a run level MUST do so, and use anyuid or restricted unless they can make a case for host network or privileged. Those components should be granted access to the protected SCCs. Each component listed here must be reviewed to determine whether it must be in run-level 1 or not, and if not, the label should be removed and appropriate SCC bindings created. If the SR-IOV operator has a genuine need to run at this level, it would at least be helpful to briefly document the reason for that as a comment above the label.
The SR-IOV operator is in charge of configuring the SR-IOV network devices of the host. So hostNetwork and privileged is a must-have for these tasks. However, I think the privileged SCC should be sufficient.
Verified this bug on 4.5.0-202005111717 1. create namespace openshift-sriov-network-operator 2. cat >og.yaml <<EOF apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: sriov-network-operators namespace: openshift-sriov-network-operator spec: targetNamespaces: - openshift-sriov-network-operator EOF | oc create -f - 3. setup the sriov operator with above version 4. Create sriovnetworknodepolicy 5. Create sriovnetwork 6. Create test pod works well.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:2409