You might receive SELinux denials when accessing files or directories mounted from the hostPath volume in a 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. This also 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 the SELinux policy for container runtimes. See This page is not included, but the link has been rewritten to point to the nearest parent document.Persistent storage using local volumes.

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 to allow the virtiofsd daemon to access these specific labels. (This content is not included.KATA-469)

Some OpenShift sandboxed containers Operator pods use container CPU resource limits to increase the number of available CPUs for the pod. These pods might receive fewer CPUs than requested. If the functionality is available inside the container, you can diagnose CPU resource issues by using oc rsh <pod> to access a 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 offline CPUs will likely change unpredictably from run to run.

As a workaround, you can use a pod annotation to request additional CPUs rather than setting a CPU limit. CPU requests that use pod annotation are not affected by this issue, because the processor allocation method is different. 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"

(This content is not included.KATA-1376)

When you set SELinux Multi-Category Security (MCS) labels in the security context of a container, the pod does not start and the following error is displayed in the pod log:

Error: CreateContainer failed: EACCES: Permission denied: unknown

The runtime does not have access to the security context of the containers when the sandboxed container is created. This means that virtiofsd does not run with the appropriate SELinux label and cannot access host files for the container. As a result, you cannot rely on MCS labels to isolate files in the sandboxed container on a per-container basis. This means that all containers can access all files within the sandboxed container. Currently, there is no workaround for this issue.

(This content is not included.KATA-1875)

The sizeLimit option for ephemeral memory volumes does not work with OpenShift sandboxed containers. The ephemeral volume size defaults to 50% of the memory assigned to the sandboxed container. It is possible to manually change the size of this volume by remounting the volume. For example, if the memory assigned to the sandboxed container is 6 GB and the ephemeral volume is mounted to /var/lib/containers, you can increase the size of this volume beyond the default 50% of the VM memory by using the following command:

$ mount -o remount,size=4G /var/lib/containers

(This content is not included.KATA-2579)

The io.katacontainers.config.hypervisor.default_vcpus and io.katacontainers.config.hypervisor.default_memory annotations follow the semantics for QEMU, which has the following limitations for peer pods:

Instead, it is recommended to use the io.katacontainers.config.hypervisor.machine_type: <instance type/instance size> annotation for flexible pod VM sizes. (This content is not included.KATA-2575, This content is not included.KATA-2577, This content is not included.KATA-2578)

During automatic upgrades from OpenShift sandboxed containers Operator 1.4.1 to version 1.5, the upgrade gets stuck in pending state.

If your subscription is set to automatic updates, then the upgrade for OpenShift sandboxed containers is installed. However, if a KataConfig CR (custom resource) is installed, then the CSV gets stuck in the pending state.

You can check the status of your Subscription object by running the following command:

$ oc get sub osc-operator -n openshift-osc-operator -o yaml

The following error appears in the status section of the Subscription object, and in the status section of the upgrade InstallPlan object:

message: 'error validating existing CRs against new CRD''s schema for "kataconfigs.kataconfiguration.openshift.io":
      error validating custom resource against new schema for KataConfig /example-kataconfig:
      [].status.runtimeClass: Invalid value: "string": status.runtimeClass in body
      must be of type array: "string"'

If you receive this error, you must uninstall, and then reinstall the OpenShift sandboxed containers Operator:

(This content is not included.KATA-2593)