Bug 2088464 - [CDI] cdi-deployment does not comply with restricted security context
Summary: [CDI] cdi-deployment does not comply with restricted security context
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Storage
Version: 4.11.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.12.0
Assignee: Alexander Wels
QA Contact: Yan Du
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-05-19 13:49 UTC by Sarah Bennert
Modified: 2023-01-24 13:36 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-01-24 13:36:17 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github kubevirt containerized-data-importer pull 2331 0 None Merged Comply with restricted security context 2022-09-28 11:19:21 UTC
Red Hat Issue Tracker CNV-18496 0 None None None 2022-12-15 08:43:53 UTC
Red Hat Product Errata RHSA-2023:0408 0 None None None 2023-01-24 13:36:30 UTC

Description Sarah Bennert 2022-05-19 13:49:58 UTC
Description of problem:
cdi-deployment logs shows info-level log message related security context issue.

Version-Release number of selected component (if applicable):
4.11

How reproducible:
100%

Expected results:
Security context configuration prevents warning from occurring. 


Additional info:

{"level":"info","ts":1652877234.7262948,"logger":"KubeAPIWarningLogger","msg":"would violate PodSecurity \"restricted:latest\": allowPrivilegeEscalation != false (container \"cdi-source-update-poller\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container \"cdi-source-update-poller\" must set securityContext.capabilities.drop=[\"ALL\"]), runAsNonRoot != true (pod or container \"cdi-source-update-poller\" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container \"cdi-source-update-poller\" must set securityContext.seccompProfile.type to \"RuntimeDefault\" or \"Localhost\")"}
{"level":"info","ts":1652877319.456313,"logger":"KubeAPIWarningLogger","msg":"would violate PodSecurity \"restricted:latest\": allowPrivilegeEscalation != false (containers \"init\", \"importer\", \"server\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (containers \"init\", \"importer\", \"server\" must set securityContext.capabilities.drop=[\"ALL\"]), runAsNonRoot != true (pod or containers \"init\", \"importer\", \"server\" must set securityContext.runAsNonRoot=true), seccompProfile (pod or containers \"init\", \"importer\", \"server\" must set securityContext.seccompProfile.type to \"RuntimeDefault\" or \"Localhost\")"}
{"level":"info","ts":1652878329.2959814,"logger":"KubeAPIWarningLogger","msg":"would violate PodSecurity \"restricted:latest\": allowPrivilegeEscalation != false (container \"importer\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container \"importer\" must set securityContext.capabilities.drop=[\"ALL\"]), runAsNonRoot != true (pod or container \"importer\" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container \"importer\" must set securityContext.seccompProfile.type to \"RuntimeDefault\" or \"Localhost\")"}

Comment 3 Yan Du 2022-06-22 12:06:11 UTC
Alexander, could you please update the bug?

Comment 4 Alexander Wels 2022-06-22 19:12:42 UTC
PR that fixes the noted issues posted.

Comment 5 Alexander Wels 2022-06-24 14:59:03 UTC
Actually after some more investigation we have many more pods that will likely need the same treatment. And when testing against Open Shift 4.10 we were not allowed to modify the secCompProfile on a pod. So we have one Open Shift requirement that we should modify the secCompProfile to localhost or runtimedefault and at the same time it blocks us from modifying the secCompProfile (which makes sense, because we could potentially set it to unconfined which is not good). So I would like to take a step back and figure out how to properly fix this. Is there a document describing how to properly do these things for Open Shift that I can take a look at?

Comment 7 Adam Litke 2022-10-11 17:37:11 UTC
For 4.11 we did part of the work.  It's not a problem to push to 4.12 because our control plane exists in a privileged namespace and our workers (Importers, etc) use their own SA that is associated with a custom SCC.

Comment 9 Yan Du 2022-10-25 02:28:55 UTC
Test on CNV-4.12.0-628, no security context error appeared in cdi-deployment, issue has been fixed.

Comment 12 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


Note You need to log in before you can comment on or make changes to this bug.