Release v0.4.0

Please see the quickstart guide for details on how to try out Confidential Containers.

Please refer to our Acronyms and Glossary pages for a definition of the acronyms used in this document.

What’s new

• This release focused on reducing technical debt. You will not observe as many new features in this release but you will be running on top of more robust code.
• Skopeo and umoci dependencies are removed with our image-rs component fully integrated
• Improved CI for SEV
• Improved container support for enclave-cc / SGX

Hardware Support

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 (s390x) running LinuxONE

The following platforms are in development:

• AMD SEV-SNP

Limitations

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 key broker services (KBS) that can be used:
    • simple-kbs: simple key broker service 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.
• 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
• 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.

CVE Fixes

None

• ←Previous
• Next→