- Shane Boulden
As a development platform, OpenShift has an internal container registry that supports DevSecOps and CI/CD workflows. But, these images could also be subject to common vulnerabilities and exposures (CVEs), and other misconfiguration. How can you scan the internal OpenShift registry for issues?
In this article, I'm going to use Red Hat Advanced Cluster Security to integrate with the OpenShift internal registry, and detect policy violations and CVEs present inside container images stored there.
What's all this about an internal registry?
OpenShift Container Platform provides a built-in container image registry that runs as a standard workload on the cluster. It provides an out-of-the-box solution for users to manage the images that run their workloads, and runs on top of the existing cluster infrastructure.
Many organisations use the internal registry as a build target. OpenShift can build container images from code, and then deploy these. The internal registry can provide a build target for these images, and is integrated with OpenShift's "source-to-image" capabilities.
In addition, the internal registry can support deployment workflows. When a new image is pushed to the internal registry, the cluster is notified of the new image and other components can react to and consume the updated image. For example, you could perform a new deployment automatically in response to pushing a new image to the internal registry.
Scanning the internal registry
Scanning the internal registry with Red Hat Advanced Cluster Security for Kubernetes currently requires some additional configuration.
Firstly we need a service account with access to the registry. You can create this in any namespace; I'm creating it in the
$ oc create sa acspull -n openshift-image-registry
We also need to provide the service account access to the registry, which we can do with the
$ oc policy add-role-to-user registry-viewer system:serviceaccount:openshift-image-registry:acspull
clusterrole.rbac.authorization.k8s.io/registry-viewer added: "system:serviceaccount:openshift-image-registry:acspull"
Now that we have a service account with the right permissions created, we need to collect the token. This will be created as a Kubernetes secret within the namespace, and you can use
oc describe to print the value.
$ oc describe secret acspull-token-jfqpq -n openshift-image-registry
Nearly there! The last step is to create a Generic Docker Registry Integration In Red Hat Advanced Cluster Security for Kubernetes. The form fields required are:
- Integration name: Internal registry
- Endpoint: image-registry.openshift-image-registry.svc:5000
- Username: acspull
- Password: Token value from above
You can see an example here:
Testing everything out
Once configured you can test out an image scan, and verify that results are returned.
Firstly, we need an image inside the registry. Let's create a new namespace, and import an image:
oc new-project devops
oc import-image quay.io/smileyfritz/log4shell-app:v0.5 --confirm
This will import the image from Quay.io to the internal OpenShift registry. We can then use
roxctl to scan the image:
$ roxctl --insecure-skip-tls-verify=true -e "central-stackrox.yourcluster.com:443" image check --image=image-registry.openshift-image-registry.svc:5000/devops/log4shell-app:v0.5
Policy check results for image: image-registry.openshift-image-registry.svc:5000/devops/log4shell-app:v0.5
(TOTAL: 4, LOW: 2, MEDIUM: 0, HIGH: 1, CRITICAL: 1)
You should now be able to find the image in the Advanced Cluster Security vulnerability dashboard:
There's a few things to look out for when integrating the OpenShift internal registry with Red Hat Advanced Cluster Security for Kubernetes.
Autogenerated registry information
Red Hat Advanced Cluster Security creates registry integrations for images it observes on the cluster, and you may need to delete these autogenerated configurations to scan images correctly. The autogenerated configurations look like this:
Internal registry hosted on another cluster
If the internal registry is hosted on another OpenShift cluster (ie; separate to where you have Advanced Cluster Security deployed), you'll need to expose the registry and then use the new route as the endpoint for the registry integration.