Populate ImageId field in container status#12787
Merged
mikebrow merged 2 commits intocontainerd:mainfrom Jan 24, 2026
Merged
Conversation
avin3sh
force-pushed
the
avin3sh-fix-populate-image-id-cri-field
branch
2 times, most recently
from
e9cc082 to
28f57bf
Compare
fuweid
reviewed
Jan 23, 2026
| // repoDigests[0] is the manifest list digest for multi-arch images. | ||
| // This overwrites imageRef (originally the platform-specific digest) | ||
| // for backwards compatibility with existing CRI consumers. | ||
| imageRef = repoDigests[0] |
Member
There was a problem hiding this comment.
could you please double check this comment? repoDigests[0] seems image.ID.
And could you please add integration test for this change? thanks
EDITED: Test should be handled in critest side.
fuweid
approved these changes
Jan 23, 2026
The CRI ImageId field was added in kubernetes/kubernetes#123508 to provide a unique image identifier on the node, separate from ImageRef which contains the manifest list digest for multi-arch images. Previously, ImageId was not populated, leaving it empty in the CRI response. This change populates ImageId with the platform-specific image config digest (stored in container.ImageRef during container creation). The ImageRef field continues to return the manifest list digest for backwards compatibility. Signed-off-by: Avinesh Singh <[email protected]>
Signed-off-by: Avinesh Singh <[email protected]>
fuweid
force-pushed
the
avin3sh-fix-populate-image-id-cri-field
branch
from
791333b to
2470af5
Compare
djdongjin
approved these changes
Jan 24, 2026
github-project-automation
Bot
moved this from Needs Triage
to Review In Progress
in Pull Request Review
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
github-project-automation
Bot
moved this from Review In Progress
to Done
in Pull Request Review
dmcgowan
changed the title
This was referenced Apr 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change populates the
ImageIdfield in the CRIContainerStatusandListContainersresponses with the platform-specific image config digest.For multi-architecture images, the existing
ImageReffield contains the manifest list digest (same across all architectures), making it impossible to determine which actual image is running on a specific node. This causes issues, such as cri-o/cri-o#7143 (likely not applicable for containerd), but more importantly it makes it difficult for any auditing or security tool consuming the CRI API to know the specific image being used on the host.CRI API introduced
image_idfield in1.30, kubernetes/kubernetes#123508, to handle exactly these shortcomings. This PR ensures that field is correctly populate.For a reference, CRI-O has implemented this via cri-o/cri-o#8115.
CRI Field Semantics After This Change
ImageRefImageIdValidation
Tested on Windows Server 2022 nodes running Kubernetes v1.30.14 with multi-arch
python:latestimage. The following differences were observed in the output ofcrictl inspect <container_id>,Before (containerd 2.2.1 without fix)
{ "status": { "id": "fd119eda70ad3fecb2b2de30c8e399f04307ad1fce6db98d9f32f1cb2f985912", "image": { "image": "docker.io/library/python:latest" }, "imageId": "", "imageRef": "docker.io/library/python@sha256:37cba1153c7a3cd4477640ce0f976f7460308f812bc29d7149532e352a97ac8b", "state": "CONTAINER_RUNNING" } }After (containerd 2.2.1 with this fix)
{ "status": { "id": "5e49b24a6dcbb8c26e8ac709e36c8e9fb2635ea0af564a2a77ffe19e4ecf9c28", "image": { "image": "docker.io/library/python:latest" }, "imageId": "sha256:901dd1e74bd316de5daf29486c05179a097ab368a527430e1230f7ec58223f69", "imageRef": "docker.io/library/python@sha256:37cba1153c7a3cd4477640ce0f976f7460308f812bc29d7149532e352a97ac8b", "state": "CONTAINER_RUNNING" } }Result:
imageId(sha256:901dd1e7...) = Platform-specific Windows image config digest (unique to this node's architecture)imageRef(sha256:37cba115...) = Multi-arch manifest list digest (same across all platforms)