Skip to content
This repository has been archived by the owner on Jul 20, 2023. It is now read-only.

Latest commit

 

History

History
76 lines (64 loc) · 4.33 KB

v0.3.0.md

File metadata and controls

76 lines (64 loc) · 4.33 KB

Release Notes for v0.3.0

Release Date: January 20th, 2023

Code Freeze: January 13th, 2023

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

What's new

  • 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, and kata-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

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 & 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 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
  • 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