What type of PR is this?

/kind feature

What this PR does / why we need it:

For confidential container, we want to have the ability to pull the image on the guest side, and not rely on the host's repository.

To achieve this, an extension to the kata shim's mount options for CreateContainer was added. Provided the right information through these options, the kata agent in the remote VM will proceed with the PullImage before handling the actual CreateContainer.

This commit adds support for this method.

As part of this, I am adding an option to the runtime configuration, making it possible to select whether or not the additional data should be sent.
We need it to be configurable, because there are use cases for confidential containers where pull-in-guest is not desired (like: sharing a volume from the host to the VM, containing the container images).

Additionally: with this feature enabled, cri-o will still comply with kubernetes' "PullImageRequest", even though the resulting container image is not used.
This can be an issue, not only in terms of resource usage: if the workload is encrypted and cri-o can't access it, cri-o will fail the PullImageRequest, and kubernetes will never send CreateContainer.
I'm looking for a way to avoid this situation, maybe making cri-o skip PullImage for a specific runtime. This will be a separate PR - suggestions are welcome.

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

Here is how I've been testing it:

Prerequisite: build/install kata from the CCv0 branch (https://github.com/kata-containers/kata-containers/tree/CCv0).
Build/install cloud-api-adaptor and related podvm image, using libvirt as the cloud provider (and have a libvirt server available that you can talk to).
(https://github.com/confidential-containers/cloud-api-adaptor/)

Add the following configuration to crio, to define new runtime classes:

• kata: regular kata container
• kata-remote: peer-pod container - in this scenario, cloud-api-adapator makes a PullImage request to the kata-agent as part of processing the CreateContainer request. This method is considered a hack, and is bound to be deprecated.
• kata-cc: confidential container - in this scenario, the changes in this PR are exercised: cri-o provides the needed information to the agent as part of the CreateContainer request, cloud-api-adaptor forwards it without doing anything more, and the agent performs the PullImage on its own.

/etc/crio/crio.conf.d/50-kata-runtimes

[crio.runtime.runtimes.kata]
  runtime_path = "/usr/local/bin/containerd-shim-kata-v2"
  runtime_root = "/run/vc"
  runtime_type = "vm"
  privileged_without_host_devices = true
  runtime_config_path = "/usr/share/defaults/kata-containers/configuration.toml"

[crio.runtime.runtimes.kata-remote]
  runtime_path = "/usr/local/bin/containerd-shim-kata-v2"
  runtime_root = "/run/vc"
  runtime_type = "vm"
  privileged_without_host_devices = true
  runtime_config_path = "/usr/share/defaults/kata-containers/configuration-remote.toml"

[crio.runtime.runtimes.kata-cc]
  runtime_path = "/usr/local/bin/containerd-shim-kata-v2"
  runtime_root = "/run/vc"
  runtime_type = "vm"
  privileged_without_host_devices = true
  runtime_config_path = "/usr/share/defaults/kata-containers/configuration-remote.toml"
  runtime_pull_image = true

The kata configuration files configuration.toml and configuration-remote.toml are the default, built and installed as part of kata-container.

• start crio
• start cloud-api-adaptor in a terminal:
  ./cloud-api-adaptor libvirt -uri="qemu+ssh://[libvirt server address]/system?no_verify=1"

Then try to load the same container, using the different runtime classes.
I'm using the following script:

runtest.sh

#!/bin/bash
set -e

RUNTIMECLASS=$1
if [ "$RUNTIMECLASS" == "" ]; then
    exit 1
fi
echo RUNNING WITH RUNTIMECLASS=$RUNTIMECLASS

PODID=$(crictl runp --runtime="$RUNTIMECLASS" sandbox.json)
CTRID=$(crictl create $PODID ctr.json sandbox.json)
crictl start $CTRID

The logs from cloud-api-adaptor show the difference of behaviour.

$ ./runtest.sh kata-remote
=> cloud-api-adaptor logs:
[...]
2023/11/09 11:14:52 [adaptor/proxy] getImageName: got image from annotations: docker.io/bitnami/nginx:latest
2023/11/09 11:14:52 [adaptor/proxy] CreateContainer: calling PullImage for "docker.io/bitnami/nginx:latest" before CreateContainer (cid: "194ef1718624d13f59f5031d1fa836a66764c0ab37b5cddfeeb76834457c12b9")
2023/11/09 11:14:55 [adaptor/proxy] CreateContainer: successfully pulled image "docker.io/bitnami/nginx:latest"
2023/11/09 11:14:55 [adaptor/proxy] StartContainer: containerID:194ef1718624d13f59f5031d1fa836a66764c0ab37b5cddfeeb76834457c12b9

$ ./runtest.sh kata-cc
=> cloud-api-adaptor logs:
[...]
2023/11/09 11:18:59 [adaptor/proxy] CreateContainer: Ignoring PullImage before CreateContainer (cid: "401347cc2cdfa5d26a3b75825163417ff08795e26c6c597f242e0485e6325484")
2023/11/09 11:19:02 [adaptor/proxy] StartContainer: containerID:401347cc2cdfa5d26a3b75825163417ff08795e26c6c597f242e0485e6325484

In addition, logging into the pod VM, I can check the kata-agent's logs in journalctl and confirm that it actually pulled the image on its own, without receiving the PullImage request

Does this PR introduce a user-facing change?

Confidential Containers: add support for pull-in-guest method