Bug 2089744

Summary: HCO should label its control plane namespace to admit pods at privileged security level
Product: Container Native Virtualization (CNV) Reporter: Simone Tiraboschi <stirabos>
Component: InstallationAssignee: Simone Tiraboschi <stirabos>
Status: CLOSED ERRATA QA Contact: Debarati Basu-Nag <dbasunag>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 4.11.0CC: alitke, dbasunag, kmajcher, phoracek, sasundar, sgott, stirabos
Target Milestone: ---   
Target Release: 4.12.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: hco-bundle-registry-v4.11.1-15 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-01-24 13:36:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2128997, 2133540, 2133541, 2133542, 2133543, 2133654, 2133655, 2133656, 2133657, 2133659, 2133660, 2140406, 2141669, 2141670, 2141671    
Bug Blocks:    

Description Simone Tiraboschi 2022-05-24 10:57:19 UTC
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:

Comment 1 Simone Tiraboschi 2022-05-24 11:01:40 UTC
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 ) ?

Comment 2 Petr Horáček 2022-05-24 11:14:16 UTC
@stirabos some of the network components use host network and host directory volume. So IIUIC we are not compatible with the restricted PSS.

Comment 3 Adam Litke 2022-05-31 12:27:42 UTC
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.

Comment 4 Simone Tiraboschi 2022-06-06 08:27:33 UTC
This change has been postponed to 4.12.

Comment 5 Simone Tiraboschi 2022-08-02 12:42:37 UTC
@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.

Comment 10 Krzysztof Majcher 2022-10-25 12:52:46 UTC
Please rerun the tests on a completely fresh cluster - that should provide good environment to verify the bug.

Comment 12 Debarati Basu-Nag 2023-01-04 13:41:23 UTC
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

Comment 13 Debarati Basu-Nag 2023-01-04 22:48:55 UTC
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

Comment 16 errata-xmlrpc 2023-01-24 13:36:17 UTC
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