Description of problem: With OCP 4.11 the pod security admission mechanism is going to be enabled by default with restricted profile. See https://kubernetes.io/docs/concepts/security/pod-security-admission/ for an intro about PSA. With PSA we can only choose between 3 Pod Security Standards: privileged, baseline, and restricted. All the pods with restricted-v2 SCC are compatible with restricted PSS but in openshift-cnv currently we also have: cdi-deployment: containerized-data-importer SCC hostpath-provisioner-csi: hostpath-provisioner-csi SCC hpp-pool: hostpath-provisioner-csi SCC cluster-network-addons-operator: anyuid SCC bridge-marker: bridge-marker SCC kube-cni-linux-bridge-plugin: linux-bridge SCC virt-handler: kubevirt-handler SCC If even one of those pods cannot be made compatible with the k8s restricted PSS ( https://kubernetes.io/docs/concepts/security/pod-security-standards/ ) HCO schould (HCO is already reconcilying openshift-cnv namespace) add: labels: pod-security.kubernetes.io/enforce: privileged pod-security.kubernetes.io/audit: privileged pod-security.kubernetes.io/warn: privileged on openshift-cnv namespace User namespace with our workloads (VMs, DVs, data-import...) are not going to be affected by this because OCP 4.11 is also going to introduce the PSa Label Synchronization Controller ( https://github.com/openshift/enhancements/blob/master/enhancements/authentication/pod-security-admission-autolabeling.md ) which is going to automaticaly relabel user namespaces according to the pod with the most permissive Security Context Constraints in that namespace. But this is not going to handle openshift-* namespaces and so this bug. Version-Release number of selected component (if applicable): 4.11 How reproducible: 100% Steps to Reproduce: 1. deploy CNV 2. check audit logs for pod-security.kubernetes.io/audit-violations in openshift-cnv 3. Actual results: OCP 4.11 is still not enforcing it but it will start soon. Expected results: No audit logs entry about pod-security.kubernetes.io/audit-violations in openshift-cnv Additional info:
Petr, Stu, Adam can you please confirm/deny that at least one of your pods is not compatible with the requirements of the restricted PSS (see: https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted ) ?
@stirabos some of the network components use host network and host directory volume. So IIUIC we are not compatible with the restricted PSS.
For HPP, HCO does not manage the CR so I am wondering if this makes a difference for this requirement. Of course we still want everything to work if someone does post a CR to deploy HPP to the cluster.
This change has been postponed to 4.12.
@dbasunag we are backporting this to CNV 4.11.1 to be sure that the upgrade from OCP 4.11.z + CNV 4.11.z -> OCP 4.12 will be smooth.
Please rerun the tests on a completely fresh cluster - that should provide good environment to verify the bug.
Moving the target version to 4.12, as majority of the dependent bugs were fixed in 4.12 with no plan to backport to 4.11.z
Verified against ================= Deployed: OCP-4.12.0-rc.6 Deployed: CNV-v4.12.0-769 ================= 17:20:19 TEST: test_cnv_pod_security_violation_audit_logs STATUS: PASSED
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 (Important: OpenShift Virtualization 4.12.0 Images security update), 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/RHSA-2023:0408