1. Proposed title of this feature request
Expose digest of the image executed in a Pod
2. What is the nature and description of the request?
When a Pod executes, its status contain information about each container that it executed, i.e. .status.containerStatuses[].imageID. Sometimes the information in this field may contain an unexpected value. For example, it may hold an image reference to a completely different registry than it was requested (see OCPBUGS-8428), or it may even include a digest for a different format of the image (oci vs. s2v1 vs. s2v2).
With a recent change in cri-o, #7149, changes the imageID attribute to include an internal cri-o ID of the image.
If a user starts a Pod with an image reference that contains a tag (an no digest), it is impossible for the user to determine the digest of the image that was actually executed.
This feature request is to provide this information, somehow, so it can be retrieved from the Pod resource.
3. Why does the customer need this? (List the business requirements here)
This is needed for auditing and security purposes.
The current behavior makes it challenging to produce an accurate SLSA Provenance. In RHTAP, we leverage Tekton Chains 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?
4. List any affected packages or components.
I believe this is mostly isolated to cri-o, but it may touch other components as well.
- is related to
-
OCPNODE-2076 Enhance CRI to fix kubelet image garbage collection
- Closed
-
OCPBUGS-43638 OKD - pod imageID reference change breaking StackRox
- Closed
-
OCPNODE-2054 Elaborate on feature: Expose digest of the image executed in a Pod
- Closed
- relates to
-
OCPBUGS-27379 Pod status imageID field no longer contains the resolved image
- Closed