Chapter 1. {sandboxed-containers-first} {sandboxed-containers-version} release notes

If you are using OpenShift sandboxed containers, you might receive SELinux denials when accessing files or directories mounted from the hostPath volume in an OpenShift Container Platform cluster. These denials can occur even when running privileged sandboxed containers because privileged sandboxed containers do not disable SELinux checks.

Following SELinux policy on the host guarantees full isolation of the host file system from the sandboxed workload by default, and provides stronger protection against potential security flaws in the virtiofsd daemon or QEMU.

If the mounted files or directories do not have specific SELinux requirements on the host, you can use local persistent volumes as an alternative. Files are automatically relabeled to container_file_t, following SELinux policy for container runtimes. See Persistent storage using local volumes for more information.

Automatic relabeling is not an option when mounted files or directories are expected to have specific SELinux labels on the host. Instead, you can set custom SELinux rules on the host in order to allow the virtiofsd daemon to access these specific labels. (BZ#1904609)

You might encounter an issue where the Machine Config Operator (MCO) pod changes to a CrashLoopBackOff state and the openshift.io/scc annotation of the pod displays sandboxed-containers-operator-scc instead of the default hostmount-anyuid value.

If this happens, temporarily change the seLinuxOptions strategy in the sandboxed-containers-operator-scc SCC to the less restrictive RunAsAny, so that the admission process does not prefer it over the hostmount-anyuid SCC.

The OpenShift sandboxed containers Operator pods that use container CPU resource limits to increase the number of available CPUs for the pod might receive fewer CPUs than requested. If the functionality is available inside the container, you can diagnose CPU resources by using oc rsh <pod> and running the lscpu command.

$ lscpu

CPU(s):                          16
On-line CPU(s) list:             0-12,14,15
Off-line CPU(s) list:            13

The list of available offline CPUs will likely change from run to run in an unpredictable manner.

As a workaround, you can use a pod annotation to request additional CPUs rather than setting a CPU limit. The method of allocating processors is different, and CPUs requested by means of pod annotation are not affected by this issue. Rather than setting a CPU limit, the following annotation must be added to the metadata of the pod:

metadata:
  annotations:
    io.katacontainers.config.hypervisor.default_vcpus: "16"

(KATA-1376)

The progress of the runtime installation is shown in the status section of the kataConfig CR. However, the progress is not shown if all of the following conditions are true:

In this case, the installation starts on the master nodes because the Operator assumes it is a converged cluster where nodes have both master and worker roles. The status section of the kataConfig CR is not updated during the installation. (KATA-1017)