Red Hat UBI Base Image Security/CVE Vulnerability for OOT driver container Image

[uMartinXu]

Summary

How to handle Red Hat UBI Base Image Security/CVE Vulnerability for OOT driver container Image.

Detail

According to the suggestion from KMM Operator project, Red Hat UBI-minimal base image is used to package the Intel data center gpu driver container image. During the RH certifying process, a CVE Vulnerability was found in this base image. This vulnerability comes from curl package addressed by CVE2023-23916. To resolve this vulnerability and pass the RH certification, we have to recreate the image by using the new UBI-minimal based image which includes the latest curl package with the CVE update.

Analysis

However, From this CVE vulnerability following potential problems are worthy us to pay attention to.

• Is the UBI-minimal base image is good and safe enough for the OOT driver container image? We know the safest image is the image that only includes the necessary packages. All the unnecessary packages will potentially bring Vulnerability risk to the image. To this issue, from Intel data center gpu driver container dockerfile, it is obviously the curl package is not used at all. So is it possible to have an OOT driver-specific base image and just include the necessary packages for OOT driver container image usage? Or a minimal base image for OOT driver container users to install the necessary packages. We all know to insmod the OOT driver module, the permissive privilege needs to run the container. So any potential vulnerability might be very dangerous for the whole cluster.

• Should all of the published OOT driver container images need to update the image and redo the certifying and publishing process In this case, if some vulnerability was found in the base image, do we really need to rebuild the image and go through the certifying process, and publish a new version of the driver container image? From certifying and publishing efforts it will be a huge effort for all the published and certified images. Image all of the published OOT driver container images are based on this vulnerable base image and needs this effort. And also upgrading the driver container image is not an easy task, the related feature is still under development in KMM project. Do we have some way to relieve people from the efforts?

Possible solutions

• 1. working out the base image tailored for the OOT driver Container image
• 2. Optimize the RH certifying and publishing process an technology to relieve this effort

Conclusion

According to April-19 KMM upstream meeting, in the future, we even can only package the kernel modules without the base image. That might be the best solution to resolve this issue

[uMartinXu]

@qbarrand @ybettan can you have a look at this issue, please?

[ybettan]

Is the UBI-minimal base image is good and safe enough for the OOT driver container image?

I am not aware of any other image which not ubi-minimal or ubi that will pass the certification process (I am not familiar enough with the process though so I may be mistaken here)

Maybe @bthurber can add some insights here.

[bthurber]

DTK image is the recommend pattern to build a needed OOT driver container from. It ultimately is based on the RHEL UBI image. The RHEL UBI image is updated every few weeks. The chain of images looks like: RHEL UBI -> OCP base images -> DTK Inherently there can be a delay between when the updated RHEL UBI image lands, OCP base images are updated and when the DTK image is rebuilt.

[uMartinXu]

According to @qbarrand, in today's KMM upstream meeting, in the future, we even can only package the kernel modules without the base image. That is the best solution to resolve this issue. Thanks @bthurber @ybettan @qbarrand. But we still need to figure out some detail in the future, like how to do the RH certification without the UBI base image.

[ybettan]

Just for clarifying. "In the future" means in KMM V2, hopefully.

[chaitanya1731]

@qbarrand any updates here? Is this taken in for the plan of KMM v2?

[bthurber]

@qbarrand any updates here? Is this taken in for the plan of KMM v2?

This isn't related to KMM. This is specific to DTK, UBI and the RH image certification process and is something we can bring to the attention of our team which handles image and operator certifications.