Chapter 3. Technology Previews
This section provides a list of all Technology Previews available in OpenShift sandboxed containers 1.8.
See Technology Preview Features Support Scope for more information.
Peer pod support for IBM Z and IBM LinuxONE
You can deploy OpenShift sandboxed containers workloads, without nested virtualization, by using peer pods on IBM Z® and IBM® LinuxONE (s390x architecture).
Jira:KATA-2030
Confidential Containers on Microsoft Azure Cloud Computing Services, IBM Z, and IBM LinuxONE
Confidential Containers provides enhanced security for cloud-native applications, allowing them to run in secure and isolated environments known as Trusted Execution Environments (TEEs), which protect the containers and their data even when in use.
Note the following limitations:
- No encryption and integrity protection of the confidential virtual machine (CVM) root filesystem (rootfs): The CVM executes inside the TEE and runs the container workload. Lack of encryption and integrity protection of the rootfs could allow a malicious admin to exfiltrate sensitive data written to the rootfs or to tamper with the rootfs data. Integrity protection and encryption for the rootfs is currently work in progress. You must ensure that all your application writes are in memory.
- No encrypted container image support: Only signed container image support is currently available. Encrypted container image support is work in progress.
- Communication between the Kata shim and the agent components inside the CVM is subject to tampering: The agent components inside the CVM are responsible for executing Kubernetes API commands from the Kata shim running on the OpenShift worker node. We use an agent policy in the CVM that turns off Kubernetes exec and log APIs for the containers to avoid exfiltration of sensitive data via the Kubernetes API. However, this is incomplete; further work is ongoing to harden the communication channel between the shim and the agent components. The agent policy can be overridden at runtime by using pod annotations. Currently, runtime policy annotations in the pod are not verified by the attestation process.
- No native support for encrypted pod-to-pod communication: Pod-to-pod communication is unencrypted. You must use TLS at the application level for all pod-to-pod communication.
- Image double-pull on the worker node and inside the CVM: The container image is downloaded and executed in the CVM that executes inside the TEE. However, currently the image is also downloaded on the worker node.
- Building the CVM image for Confidential Containers requires the OpenShift sandboxed containers Operator to be available in the cluster.
Jira:KATA-2416
