Published on
 // 4 min read

Scanning the OpenShift Internal Registry


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 openshift-image-registry namespace:

$ oc create sa acspull -n openshift-image-registry
serviceaccount/acspull created

We also need to provide the service account access to the registry, which we can do with the registry-viewer role:

$ oc policy add-role-to-user registry-viewer system:serviceaccount:openshift-image-registry:acspull 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
token: eyJhbGciOiJSUzI1NiIs...

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:

Internal registry config

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 --confirm

This will import the image from to the internal OpenShift registry. We can then use roxctl to scan the image:

$  roxctl --insecure-skip-tls-verify=true -e "" 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


You should now be able to find the image in the Advanced Cluster Security vulnerability dashboard:

ACS Vulnerability Scan


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:

Autogenerated registry

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.