FAQ: Image SHA Digests vs. Image Tags

1. Why can’t contents of image registry be mirrored using tags?

• Red Hat OpenShift Container Platform 4 content such as a release image or CSV is a pointer to a set of images.

• To provide guarantees of the image that is being run for a given release, a manifest SHA ID is used which expresses the intended running state for a container in a better way.

• Thus, the reason a image SHA is used instead of a tag is because a tag can be pushed to a disconnected mirror and be overwritten, making it challenging to diagnose issues in knowing what content is being run.

To understand the reference to a release image and the usage of image SHA better, run following command to check the release image details.

$ oc adm release info

2. Why can't the /etc/containers/registries.conf file be modified directly on nodes to allow mirroring using image tag?

• By default, the nodes are populated with default template for /etc/containers/registries.conf file by Machine Config Operator(MCO). Thus, the file is managed by controllers running in the Machine Control Daemon(MCD). So if it's manually edited then it will cause content mismatch errors in MCD which would break the cluster to prevent further upgrades. So, it is not recommended to modify these files directly.

• The supported changes to these files can be done through Content from github.com is not included.ContainerRuntimeConfig CRD for /etc/crio/crio.conf file and This page is not included, but the link has been rewritten to point to the nearest parent document.Image and ImageContentSourcePolicy CRDs for /etc/containers/registries.conf file.

3. Is it fine to re-tag an already released tag in order to use CVE Respins and automatic updates?

• Re-tagging allows for cluster skew to go undetected for the content that is shipped.

• So can't determine if a cluster is running insecure content because the tag may or may not have been updated.

• The operator is responsible for providing the updates to the operands that it is responsible for, this includes CVE respins.

4. Since OLM manifests can be changed on cluster, could the operator deployment be updated to include different SHA’s?

• Changing the operator deployment to include different SHA's would still convey that different content is being run since the expected correct content is already known.

• This would allow to quickly diagnose if the issue is in released content itself that is provided by Red Hat and is supportable or if the end user has changed and moved outside the support guidelines.