When the container images are included in the ISO they must be stored to the host0 on boot. When the host boots, a service will run to make the container images available before other services attempt to pull these images. There are two potential paths, both with tradeoffs:
1. The service creates a container to run a registry, either `docker-registry`
or `quay` (note that only `docker-registry` is in the release image).
`oc-mirror` is used to publish the contents of the tarfile to the registry.
The `/etc/containers/registries.conf` is set up to use this
local registry so all accesses to the container images use it.
In this case, both the registry and `oc-mirror` binaries would need to be
included in the ISO as they are not part of CoreOS.

2. The service does not create a registry, instead it unpacks the
tarfile and pushes the container images to container storage using
`skopeo`. All pulls of the container images come directly from this
container storage, aka [pre-pulled images](https://kubernetes.io/docs/concepts/containers/images/#pre-pulled-images).
In this case the registry and `oc-mirror` binaries would not need to be
included.

For scenario 1, in a multi-node cluster configuration, e.g. 3 control
plane nodes, the registry would only be created on Node0. All other nodes would
have their registries.conf set to retrieve container images from this registry.
This is also true when the other nodes boot into the final image. This method
uses standard tools (`oc-mirror`, registry) but does require their inclusion in
the ISO. Since the registry is local it will not be necessary to provide a
pull-secret to access it.