Known issues and limitations

Expired Customer Root Key (CRK) causes CCCO shutdown

If the Customer Root Key (CRK) is expired, the CCCO virtual machine (VM) reboots. During the boot process, the CCCO rechecks whether the CRK is expired. If it is expired, the CCCO goes into a shutdown state.

Red Hat OpenShift Container Platform upgrade breaks workloads

Upgrading the Red Hat OpenShift Container Platform version will break the running workloads.

Pod deletion issue

When attempting to delete a pod (for example, Nextcloud) using the standard delete command, the pod may fail to terminate properly and remain in the Terminating state indefinitely. This issue has been observed in both Bare Metal and Peer Pod deployment environments.

You must use the following force delete command to remove pods that are stuck in the Terminating state:

oc delete po attestation-encrypted -n coco-pp-e2e-test-4f0ffadb -f

Persistent volume support is not available for Peer Pod deployments

For Peer Pod deployments, only ephemeral storage is supported. Persistent volumes are not supported.

For Bare Metal deployments, persistent block storage is supported. For more information, see Volumes.

Remote attestation is not supported

Remote attestation of the environment is not available in this release.

Memory and state protection constraints

For limitations related to memory and state protection, see IBM Secure Execution for Linux.

Upgrade restriction during active workloads

OpenShift Sandboxed Containers (OSC) must not be upgraded while workloads are actively running, as this can lead to compatibility issues and service disruption. Before upgrading OSC, stop all active workloads. Then upgrade OSC to the latest version, load the corresponding IBM Confidential Computing Containers for Red Hat OpenShift Container Platform image, and restart the workloads to restore compatibility.

Masking and mounting

Mounted masked contracts are read-only, and Bare Metal deployments require successful logging stack initialization before masking is applied.

Registry mapping

Registry mapping has the following limitations:

• It transforms only image references. It does not change the container name.
• Host-side image pulls from private registries are not supported. Private registry pulls remain a guest-side operation.

Guest-pulled container images (Kata Containers 3.28+ behaviour change)

Kata Containers 3.28 introduced a behaviour change that affects guest-pulled container images. This change is present in CCCO 1.2.2 (Kata 3.31) but not in CCCO 1.1.x (Kata 3.25). For full details, see the upstream Kata Containers Limitations documentation.

Workloads whose images already run under a non-root user (as defined by the USER instruction in the Dockerfile) are not affected, provided runAsUser is explicitly set in the pod spec to the same user as the image's USER instruction.

For all other workloads, set runAsUser: 0 in the container security context as a workaround:

securityContext:
  runAsUser: 0