Description of problem: ----------------------- Test run[1] that looks for 'pod security violation entries' in audit logs,against 4.11.1-20, found few audit violation. [1] - https://main-jenkins-csb-cnvqe.apps.ocp-c1.prod.psi.redhat.com/view/cnv-tests%20runner/job/cnv-tests-runner/4297/consoleFull. This bug is to fix violation in 'kube-rbac-proxy' container. <snip> 'pod-security.kubernetes.io/audit-violations': 'would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (containers "manager", "kube-rbac-proxy" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (containers "manager", "kube-rbac-proxy" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or containers "manager", "kube-rbac-proxy" must set securityContext.runAsNonRoot=true), seccompProfile (pod or containers "manager", "kube-rbac-proxy" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")'}} </snip> Version-Release number of selected component (if applicable): ------------------------------------------------------------- 4.11.1-20 How reproducible: ----------------- Always Expected results: ----------------- No audit-violation to be found
I believe that this was addressed via https://github.com/kubevirt/cluster-network-addons-operator/pull/1404 in v4.11.1-29. The problem is that errata is stuck on a build that is two weeks old.
Still happens on CNV (HCO bundle) v4.11.1-49 (IIB: 346131) ose-kube-rbac-proxy: v4.11 Reproduction scenario: I Ran the same tests that was run in the original bug scenario (https://main-jenkins-csb-cnvqe.apps.ocp-c1.prod.psi.redhat.com/view/cnv-tests%20runner/job/cnv-tests-runner/4297/consoleFull), with https://code.engineering.redhat.com/gerrit/c/cnv-tests/+/430017, which was also used in the original scenario, cherry-picked. * I ran from the cluster executor rather than from the Jenkins test job. $ poetry run pytest -svv -o log_cli=true tests/install_upgrade_operators/pod_security/test_pod_security_audit_log.py --bugzilla --jira --junit-xml xunit_results.xml --tc=region:USA --tb=native --cluster-sanity-skip-storage-check Result (from the test output log): 'pod-security.kubernetes.io/audit-violations': 'would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (containers "manager", "kube-rbac-proxy" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (containers "manager", "kube-rbac-proxy" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or containers "manager", "kube-rbac-proxy" must set securityContext.runAsNonRoot=true), seccompProfile (pod or containers "manager", "kube-rbac-proxy" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")'
Upstream for 4.11 has the proper fixes https://github.com/kubevirt/cluster-network-addons-operator/blob/v0.76.2/manifests/cluster-network-addons/0.76.2/operator.yaml#L207-L217. @ysegev Can you dump the cluster-network-addons-operator pod yaml ?
This workload is fine it has the proper scc openshift.io/scc: restricted-v2 We are facing a false negative here also the yaml has the proper security context thing (that's why it has proper scc)
Hi Sas, Quique suspects that the audit violations, which are reported here, are actually related to old pods from previous installation of CNV on the cluster, and not from the current CNV. Is there a way of running the test without auditing old remainders? Thanks, Yossi
(In reply to Yossi Segev from comment #6) > Hi Sas, > > Quique suspects that the audit violations, which are reported here, are > actually related to old pods from previous installation of CNV on the > cluster, and not from the current CNV. > Is there a way of running the test without auditing old remainders? > > Thanks, > Yossi Hi Yossi, I am unaware of any such mechanism to ignore the older audits. Very naive thinking is to trigger the test with the new cluster and make sure not to observe the pod violation in audit log
I have just run this test on a fresh cluster (with CNV 4.11.1), and the same failure still occurs.
After discussing this issue offline, we came to a conclusion that while the component should be safe with the default security context it gets from OpenShift, we need to explicitly set it to silence the audit log.
Followed same steps from comment 2. Still able to see the violation: 'pod-security.kubernetes.io/audit-violations': 'would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (containers "manager", "kube-rbac-proxy" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (containers "manager", "kube-rbac-proxy" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or containers "manager", "kube-rbac-proxy" must set securityContext.runAsNonRoot=true), seccompProfile (pod or containers "manager", "kube-rbac-proxy" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")' Installed CNAO version: v4.11.2-1 CNV version: 4.11.2-10 CNI plugin: 4.11.2-1 Failed ON_QA.
Verified by running the same scenario from comment #2. OCP version: 4.12.0-rc.2 CNV 4.12.0-769
(In reply to Yossi Segev from comment #13) > Verified by running the same scenario from comment #2. > > OCP version: 4.12.0-rc.2 > CNV 4.12.0-769 Also verified on 2 upgraded clusters: OCP+CNV 4.11->4.12 OCP+CNV 4.10->4.12 (EUS upgrade).
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