Project: Confidential Containers (Provisioning / Security & Compliance)
File: v0.5.0.md

Release Date: 2023-04-14 Warning This release includes breaking changes to the format of encrypted images. See below for more details. Images that were encrypted using tooling from previous releases will fail with this release. The process for validating signed images is also slightly different. Please see the for details on how to try out Confidential Containers. Please refer to our and pages for a definition of the acronyms used in this document. Process-based isolation is now fully supported with SGX hardware added to enclave-cc CI Remote hypervisor support added to the CoCo operator, which helps to enable creating containers as peer pods, either locally, or on Cloud Service Provider Infrastructure. See for more information and installation instructions. is published to identify all confidential resources. Different KBCs now share image encryption format allowing for interchangeable use. Generic Key Broker System (KBS) is now supported. This includes the itself, which relies on the for attestation evidence verification. Reference Values are provided to the `AS` by the . Currently only TDX and a sample mode are supported with generic KBS. Other platforms are in development. SEV configuration can be set with annotations. SEV-ES is now tested in the CI. Some developmental SEV-SNP components can be manually enabled to test SNP containers without attestation. Confidential Containers is tested with attestation on the following platforms: Intel TDX AMD SEV(-ES) Intel SGX The following platforms are untested or partially supported: IBM Secure Execution (SE) on IBM zSystems (s390x) running LinuxONE The following platforms are in development: AMD SEV-SNP The following are known limitations of this release: Platform support is currently limited, and rapidly changing Image signature validation with AMD SEV-ES is not covered by CI. s390x does not support cosign signature validation SELinux is not supported on the host and must be set to permissive if in

Attestation and key brokering support varies by platform. The generic KBS is only supported on TDX. Other platforms have different solutions. The format of encrypted container images is still subject to change The container image format itself may still change The tools to generate images are not in their final form The image format itself is subject to change in upcoming releases Image repository support for encrypted images is unequal CoCo currently requires a custom build of `containerd` The CoCo operator will deploy the correct version of `containerd` for you Changes are required to delegate `PullImage` to the agent in the virtual machine The required changes are not part of the vanilla `containerd` The final form of the required changes in `containerd` is expected to be different `crio` is not supported CoCo is not fully integrated with the orchestration ecosystem (Kubernetes, OpenShift) OpenShift support is not yet complete. Existing APIs do not fully support the CoCo security and threat model. Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host Container image sharing is not possible in this release Container images are downloaded by the guest (with encryption), not by the host As a result, the same image will be downloaded separately by every pod using it, not shared between pods on the same host. The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet. We track our status with the OpenSSF Best Practices Badge, which increased from 49% to 64% at the time of this release. All CoCo repos now have automated tests, including linting, incorporated into CI. Vulnerability reporting mechanisms still need to be created. Public github issues are still appropriate for this release until private reporting is established. None