release: release notes for v0.13.0

Lots of nice updates in this release.

Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
This commit is contained in:
Tobin Feldman-Fitzthum 2025-03-21 12:52:30 -04:00 committed by Tobin Feldman-Fitzthum
parent c7a90f87ec
commit f47f28ca22

88
releases/v0.13.0.md Normal file
View File

@ -0,0 +1,88 @@
# Release Notes for v0.13.0
Release Date: March 24th, 2025
This release is based on [3.15.0](https://github.com/kata-containers/kata-containers/releases/tag/3.13.0) of Kata Containers
and [v0.11.0](https://github.com/confidential-containers/enclave-cc/releases/tag/v0.11.0) of enclave-cc.
Kata and the CoCo components share an MSRV of 1.80.0.
Please see the [quickstart guide](https://confidentialcontainers.org/docs/getting-started/) or [project documentation](https://confidentialcontainers.org/docs) for more information.
## What's new
* AMD SEV(-ES) support has been deprecated and will be removed in the next release.
* AMD SEV-SNP deployments are compatible with upstream (6.11+) host kernels.
* Trustee uses ECDH keys by default for KBS protocol.
* Reliabilty of image pulling has been improved (bug fixes below).
* The repository field of the resource URI is no longer optional.
* TDX Attestation uses configfs-tsm based reports only and disables the libtdx-attest fallback.
* Trustee documentation added to project website.
* Trustee attestation policy improved for TDX.
* Blocking logs endpoint with policy can no longer cause deadlocks.
## Bug Fixes
* Fixed an issue where pulling images with many layers failed due to exceeding the 4KB length limit on mount parameters.
* Fixed an issue where image whiteout files appeared in the unpacked container filesystem due to the guest's tmpfs not supporting xattr.
* Fixed an issue where the RCAR handshake in the KBS protocol did not treat JWE protected header as AEAD.
## Hardware Support
Attestation is supported and tested on three platforms: Intel TDX, AMD SEV-SNP, and IBM SE.
Not all features have been tested on every platform, but those based on attestation
are expected to work on the platforms above.
Make sure your host platform is compatible with the hypervisor and guest kernel
provisioned by CoCo.
This release has been tested on the following stacks:
### AMD SEV-SNP
* Processor: AMD EPYC 7413
* Kernel: 6.12.0-snp-host-adc218676 (upstream 6.11+)
* OS: Ubuntu 22.04.4 LTS
* k8s: v1.30.1 (Kubeadm)
* Kustomize: v4.5.4
### Intel TDX
* Kernel: [6.8.0-1004-intel](https://git.launchpad.net/~kobuk-team/ubuntu/+source/linux-intel/tree/?h=noble-main-next)
* OS: Ubuntu 24.04 LTS
* k8s: v1.30.2 (Kubeadm)
* Kustomize: v5.0.4-0.20230601165947-6ce0bf390ce3
### Secure Execution on IBM zSystems (s390x) running LinuxONE
* Hardware: IBM Z16 LPAR
* Kernel: 5.15.0-113-generic
* OS: Ubuntu 22.04.1 LTS
* k8s: v1.28.4 (Kubeadm)
* Kustomize: v5.3.0
## Limitations
The following are limitations and known issues with this release.
* Credentials for authenticated registries are exposed to the host.
* Not all features are tested on all platforms.
* Nydus snapshotter support is not mature.
* Nydus snapshotter sometimes fails to pull an image.
* Host pulling with Nydus snapshotter is not yet enabled.
* Nydus snapshotter is not supported with enclave-cc.
* Pulling container images inside guest may have negative performance implications including greater resource usage and slower startup.
* `crio` support is still evolving.
* Platform support is rapidly changing
* SELinux is not supported on the host and must be set to permissive if in use.
* Complete integration with Kubernetes is still in progress.
* Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
* Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
* The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
* Container metadata such as environment variables are not measured.
* The Kata Agent allows the host to call several dangerous endpoints
* Kata Agent does not validate mount requests. A malicious host might be able to mount a shared filesystem into the PodVM.
* Policy can be used to block endpoints, but it is not yet tied to the hardware evidence.
## CVE Fixes
None