add the gpg check for the rpm packages in the container certification

[jinhli]

Is your feature request related to a problem? Please describe.

When I supported [Beijing VirtAI Technology Co., Ltd.] to certify their image , the health index showed "D" even they used the latest ubi . And Lukas helped to run the command line "docker history harbor.virtaitech.com/redhat/orion-gui-controller-all-in-one:3.1.2-ubi_latest --no-trunc | grep yum.repos.d", it showed the non-redhat repos was used in this image. After I checked with the partner, they confirmed, they did use [https://mirrors.aliyun.com/repo/Centos-vault-8.5.2111.repo](https://mirrors.aliyun.com/repo/Centos-vault-8.5.2111.repo%60) because the UBI repo was slow.

[snip]
/bin/sh -c rm -f /etc/yum.repos.d/ubi.repo && curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-vault-8.5.2111.repo && sed -i -e '/mirrors.cloud.aliyuncs.com/d' -e '/mirrors.aliyuncs.com/d' /etc/yum.repos.d/CentOS-Base.repo && yum clean all && yum makecache && curl -fsSL https://rpm.nodesource.com/setup_14.x | bash - && dnf install -y nodejs -y && yum install gcc-c++ make -y && curl -sL https://dl.yarnpkg.com/rpm/yarn.repo | tee /etc/yum.repos.d/yarn.repo && yum install yarn -y 350MB
[/snip]

Describe the solution you'd like.

add gpg check for ubi rpm, if non-redhat repo is used, failed the test

[acornett21]

@jinhli I'm confused by this and what the actually ask is, for the BasedOnUBI check preflight calls pyxis with all the layers to see if the image is based on UBI, if this container passed that check, but doesn't pass our scanner, then this is something I feel should be fixed elsewhere in our tooling, and not in preflight.

Also, if we need to change a check, that ask needs to come from the business.

[jinhli]

@acornett21 let me explain more, if partner use a UBI to build the image, but they used non-redhat repo to install some packages, is that acceptable for the certification?

[acornett21]

Here are the requirements for the policies in preflight

https://access.redhat.com/documentation/en-us/red_hat_software_certification/8.49/html/red_hat_openshift_software_certification_policy_guide/assembly-requirements-for-container-images_openshift-sw-cert-policy-introduction

[jfrancin]

yeah we don't restrict what third party sources of packages the partners desire to use in their containers. I had a partner who had .repo files for Oracle Linux as well as UBI in their container's /etc/yum.repos.d/ directory, and some 200+ packages in their userland were from Oracle Linux instead of UBI or RHEL. And they wondered why Clair excluded those 200+ packages from security scanning - they weren't Red Hat sourced.

[jinhli]

though there is no this requirement for using non-ubi or RHEL repo to install the packages, it might has some security risk when they use that repos

[lslebodn]

I had a partner who had .repo files for Oracle Linux as well as UBI in their container's /etc/yum.repos.d/ directory, and some 200+ packages in their userland were from Oracle Linux instead of UBI or RHEL.

The same can happen with centos and many rhel derivatives.

Debugging issues from "clair" is not really straightforward :-)

Checking gpg keys would helped a bit. But if it is fine to mix UBI content from rhel and rpms from centos(or any other binary compatible derivatives) than new check is not needed. Maybe it should be just better documented how to analyze
issues with clair scans. @jfrancin Debugging/troubleshooting took quite a long.

[acornett21]

I don't think there will be any movement on implementing this, since there is no requirement around this, going to close this issue. If we need it (or the business approves) we can re-open in the future.