mirror of
https://github.com/confidential-containers/confidential-containers.git
synced 2025-10-20 23:12:32 +00:00
release: release notes for v0.16.0
Another great release with a lot of features, bug fixes, and a couple things we are deprecating. Signed-off-by: Tobin Feldman-Fitzthum <tobinf@protonmail.com>
This commit is contained in:
committed by
Tobin Feldman-Fitzthum
parent
ee57970282
commit
3c25b5403b
104
releases/v0.16.0.md
Normal file
104
releases/v0.16.0.md
Normal file
@@ -0,0 +1,104 @@
|
||||
# Release Notes for v0.16.0
|
||||
|
||||
Release Date: September 26th, 2025
|
||||
|
||||
This release is based on [3.21.0](https://github.com/kata-containers/kata-containers/releases/tag/3.21.0) of Kata Containers
|
||||
and [v0.11.0](https://github.com/confidential-containers/enclave-cc/releases/tag/v0.11.0) of enclave-cc.
|
||||
|
||||
Trustee and the guest components use KBS protocol v0.4.0.
|
||||
|
||||
Please see the [quickstart guide](https://confidentialcontainers.org/docs/getting-started/) or [project documentation](https://confidentialcontainers.org/docs) for more information.
|
||||
|
||||
## Deprecation Notices
|
||||
* Support for process-based confidential computing via enclave-cc will be removed in the v0.18.0 release.
|
||||
The enclave-cc project will be archived.
|
||||
* This will be the last release of CoCo and Trustee that supports `simple` attestation tokens.
|
||||
Today, EAR attestation tokens are the default, but Trustee can be configured to use `simple` tokens.
|
||||
This option will be removed.
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
* Previously the Init-Data was set for a pod via the `io.katacontainers.config.runtime.cc_init_data` annotation.
|
||||
Now the `io.katacontainers.config.hypervisor.cc_init_data` annotation must be used.
|
||||
|
||||
## What's New
|
||||
|
||||
* The affirming resource policy now checks that every submod is affirming. With multi-device attestation,
|
||||
KBS policies should be aware of all submods.
|
||||
* Experimental support for attesting some NVIDIA GPUs, such as the H100. Either ITA or the Trustee
|
||||
Attestation Service can be used to verify the device evidence, with some limitations.
|
||||
* Experimental support for using pre-provisioned VMs in cloud-api-adaptor via "bring-your-own-machine (BYOM) provider
|
||||
* Runtime measurements can be extended from inside a workload container using a REST API.
|
||||
* Improved support for runtime measurements with AAEL on TDX
|
||||
* Trustee supports AMD-SNP guests with report version 5.
|
||||
* Additional/improved TCB claims generated by TDX verifier.
|
||||
* Extractor modules can now receive configuration if required.
|
||||
* SWID/RIM-IM extractor improved.
|
||||
* Confidential guest kernel updated to v6.16.7 with certain security-focused configs.
|
||||
* CSV verifier supports AAEL.
|
||||
* Eventlog parsing supports SM3 hashes.
|
||||
* A default GPU attestation policy is provided by Trustee, but it is very limited.
|
||||
* eHSM sealed secret backend no longer enabled by default.
|
||||
* evidence-getter tool now exposes primary and additional evidence.
|
||||
|
||||
## Bug Fixes
|
||||
|
||||
* Fixed issue where Init-Data checks could be maliciously bypassed when using dm-verity rootfs, such as with the base `kata-qemu-tdx` runtime. [GHSA-989w-4xr2-ww9m](https://github.com/kata-containers/kata-containers/security/advisories/GHSA-989w-4xr2-ww9m)
|
||||
* Fixed issue with attestation service policy endpoint permissions
|
||||
* Fixed issue with AR4SI vectors containing underscores
|
||||
* Various RUST advisories resolved by updating crates.
|
||||
|
||||
## 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.16.1
|
||||
* OS: Ubuntu 22.04.4 LTS
|
||||
* k8s: v1.33.0 (Kubeadm)
|
||||
* Kustomize: v5.6.0
|
||||
|
||||
### Intel TDX
|
||||
|
||||
* Kernel: [6.8.0-1028-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
|
||||
|
||||
### IBM Secure Execution for Linux
|
||||
|
||||
* Hardware: IBM Z16 LPAR
|
||||
* Kernel: 6.8.0-60-generic
|
||||
* OS: Ubuntu Ubuntu 24.04.2 LTS
|
||||
* k8s: v1.31.1 (Kubeadm)
|
||||
* Kustomize: v5.7.1
|
||||
|
||||
## 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.
|
||||
* There is an experimental option to force guest image pull without a snapshotter.
|
||||
This is also not mature.
|
||||
* 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.
|
Reference in New Issue
Block a user