Release Date: January 20th, 2023
Code Freeze: January 13th, 2023
Please see the quickstart guide for details on how to try out Confidential Containers
- Support for pulling images from authenticated container registries. See design info.
- Significantly reduced resource requirements for image pulling
- Attestation support for AMD SEV-ES
kata-qemu-tdx
supports and has been tested with Verdictd- Support for
get_resource
endpoint with SEV(-ES) - Enabled cosign signature support in enclave-cc / SGX
- SEV attestation bug fixes
- Measured rootfs now works with
kata-clh
,kata-qemu
,kata-clh-tdx
, andkata-qemu-tdx
runtime classes. - IBM zSystems / LinuxONE (s390x) enablement and CI verification on non-TEE environments
- Enhanced docs, config, CI pipeline and test coverage for enclave-cc / SGX
Confidential Containers is tested with attestation on the following platforms:
- Intel TDX
- AMD SEV
The following platforms are untested or partially supported:
- Intel SGX
- AMD SEV-ES
- IBM Secure Execution (SE) on IBM zSystems & 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
- AMD SEV-ES is not tested in the CI.
- Image signature validation has not been tested with AMD SEV.
- s390x does not support cosign signature validation
- SELinux is not supported on the host and must be set to permissive if in use.
- Attestation and key brokering support is still under development
- The disk-based key broker client (KBC) is used for non-tee testing, but is not suitable for production, except with encrypted VM images.
- Currently, there are two KBS that can be used:
- simple-kbs: simple key broker service (KBS) for SEV(-ES).
- Verdictd: An external project with which Attestation Agent can conduct remote attestation communication and key acquisition via EAA KBC
- The full-featured generic KBS and the corresponding KBC are still in the development stage.
- For developers, other KBCs can be experimented with.
- AMD SEV must use a KBS even for unencrypted images.
- The format of encrypted container images is still subject to change
- The oci-crypt 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
- The CoCo operator will deploy the correct version of
- CoCo is not fully integrated with the orchestration ecosystem (Kubernetes, OpenShift)
- OpenShift is a non-starter at the moment due to its dependency on CRI-O
- Existing APIs do not fully support the CoCo security and threat model. More info
- 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. More info
- 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 to 49% at the time of this release.
- The main gaps are in test coverage, both general and security tests.
- Vulnerability reporting mechanisms also need to be created. Public github issues are still appropriate for this release until private reporting is established.
None