The attribute .status.containerStatuses[].imageID displays an unexpected registry in some cases.

4.12.0

Always

1. Make a copy of the UBI image to a personal repository, for example:

skopeo copy --all docker://registry.redhat.io/ubi8:latest docker://quay.io/lucarval/ubi8:latest

The digest for the amd64 ubi8 image, right now, is sha256:b7e686e30346e9ace664fa09c0275262f8b9a443ed56d22165a0e201f6488c13. So both of these are valid and point to the same image:

*registry.redhat.io/ubi8@sha256:b7e686e30346e9ace664fa09c0275262f8b9a443ed56d22165a0e201f6488c13
*quay.io/lucarval/ubi8@sha256:b7e686e30346e9ace664fa09c0275262f8b9a443ed56d22165a0e201f6488c13

2. Load the copy of the UBI image into each cluster node. To do so, list nodes with oc get node, then for each node: 

oc debug node/<node>
chroot /host
podman pull quay.io/lucarval/ubi8@sha256:b7e686e30346e9ace664fa09c0275262f8b9a443ed56d22165a0e201f6488c13

Now each node has the UBI image in its cache. Notice that the image was pulled through my personal repo.

3. Start a Pod that uses the UBI image from its original repository, for example:

echo '
---
kind: Pod
apiVersion: v1
metadata:
  generateName: img-test-pod-
spec:
  serviceAccount: default
  containers:
    - name: step-hello
      command:
        - sleep
        - infinity
      image: >-
        registry.redhat.io/ubi8@sha256:b7e686e30346e9ace664fa09c0275262f8b9a443ed56d22165a0e201f6488c13
' | oc create -f -

The imageID in the pod's container lists a different repository than what was provided in the pod spec:

🐚 oc get pod img-test-pod-c4m55 -o json | jq '.status.containerStatuses'
[
  {
    "containerID": "cri-o://f0296139333367a75f962b0710457f98031454b2f1e0cf0d82c14a5388c2490b",
    "image": "registry.redhat.io/ubi8@sha256:b7e686e30346e9ace664fa09c0275262f8b9a443ed56d22165a0e201f6488c13",
    "imageID": "quay.io/lucarval/ubi8@sha256:b7e686e30346e9ace664fa09c0275262f8b9a443ed56d22165a0e201f6488c13",
    "lastState": {},
    ...
  }
]

The imageID should have the same repository as the one provided in the Pod spec.

The reference in imageID contains a digest, so we do have the reassurance that the requested image was indeed used. However, the current behavior makes it challenging to produce an accurate SLSA Provenance[0]. In HACBS/Stonesoup, we leverage Tekton Chains[1] to record details about how an image was built. The intention is to use this information at a later time to evaluate policies, for example: did all containers used in building image X come from a reputable repository? Right now, when an image from registry.redhat.io/openshift4/ose-cli is used, sometimes it is reported as coming from quay.io/openshift-release-dev/ocp-v4.0-art-dev.