Epic Goal

• Prevent CRI-O from failing when we try to create a confidential container with an encrypted container image

Why is this important?

• CRI-O is still trying to pull the image, and fails when trying to read the encrypted layers. This blocks the container creation process.

Scenarios

Acceptance Criteria 

(The Epic is complete when...)

1. ..
2. ..
3. ..

Additional context:

A problem we have with guest pull implementation is that it doesn't modify cri-o's behaviour on the PullImage request: it still tries to pull the image in its own repository (on the host) before doing the CreateContainer request.
This is not only a waste of resources: if the container image is encrypted, cri-o will fail to prepare the image, and cause an error that will prevent the creation of the container (see KATA-2591).

To avoid that, we can add a configuration option for the runtime and use it to skip the image pull. Then we need to modify crio to be able to prepare a container bundle and report proper information about the running container without the image being in its repository.

This work will be tracked by KATA-2480, with KATA-2972 used to identify the scope of changes.