In order to support Confidential Containers in CRI-O, we have added the ability for cri-o to let the kata runtime pull the container image in the guest VM, ignoring the image that CRI-O have pulled on the host.
See: #7471

This does not prevent CRI-O from pulling the image, but the image is ignored, which is fine from the Confidential Containers point of view.

Now pulling the image requires reading its layer. In the case of encrypted images, since the decryption key may not be available to CRI-O, the pull will fail, preventing any further progress in the container creation.

In order to avoid that, we tried to prevent the pull from happening.
Answering to Kubernetes' "Pull request" with an acknowledgement is easy enough, and allows to proceed with CreateContainer. But then we faced issues in CRI-O itself.

During the CreateContainer phase, CRI-O needs to prepare the storage for the container, and generate the spec file.
Those actions are performed by the createSandboxContainer() function.

It requires using the container image layers as the base for the storage, and need access to the image's metadata (manifest and config).
Since the image was not downloaded, the function fails because it doesn't find the required information.

What we need

In order to properly start a container with Confidential Containers, we need CRI-O to create a folder that can be used as the working directory for the runtime process. It doesn't need to contain the rootfs of the container, but the other files usually found there should be available (e.g: config.json file with appropriate settings).

We also need to ensure that CRI-O can still report the right container status to Kubernetes (e.g: image digest).

What I tried so far

I've tried to modify the createSandboxContainer() function to use empty values or sane default values wherever possible when we are in the "Confidential Containers" case. This leads to a lot of changes everywhere in the function, and ended up with failures outside of it, including in kata, because of missing information.

In order to get actual meaningful settings, I tried pretending that the image to use was the pause image.
The change is simpler, but then we end up reporting to kubernetes that the container is running the pause image, and CRI-O tells the kata agent to run the pause image's command line.

This work can be reviewed here: #8008
I've stopped digging in this direction when I realized I would need the image's metadata anyway.

Image manifest and config

The whole problem seems to be that the manifest and config are not available to cri-o when it prepares the container storage.

In an encrypted image scenario, we want to avoid reading the layers (which are encrypted), but accessing the manifest and config should be possible.
If that's the case, I would need a way to download/access those information without involving the download/decryption of the layers.

At the moment, cri-o is pulling the image using a single call to a "copy.Image()"
function from the containers/image module.
I've tried to find a way to pull only the metadata with this module, but failed to find the right way to do it.

This is my understanding so far, based on the above investigations, but I really need confirmation and guidance from the cri-o community to confirm that, and to understand how to proceed from there.