Files
confidential-containers/releases/v0.3.0.md
Tobin Feldman-Fitzthum 6ef8992bc0 releases: fix dead links in release notes
Our link checker is having problems with GH redirects, so let's update
these links to point to the right place (even for the old releases).

Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
2025-01-23 13:04:01 -05:00

4.4 KiB

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