# Release Notes for v0.18.0

Release Date: January 22nd, 2026

This release is based on [3.25.0](https://github.com/kata-containers/kata-containers/releases/tag/3.25.0) of Kata Containers

This release uses v0.17.0 of Trustee and guest components.
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 has been removed.
* The CoCo operator has been deprecated. The project is now installed via a Helm [chart](https://github.com/confidential-containers/charts).
* The Cloud API Adaptor has dropped support for the experimental Secure Comms mode.
* The Cloud API Adaptor has dropped support for the vSphere provider.
* The Cloud API Adaptor is moving away from building guest images with packer in favor of mkosi.
  Support for packer images will be dropped in some future release.

## What's New

* NVIDIA Hopper GPUs can be attached to a confidential workload and automatically attested with Trustee.
* Improvements to Trustee PKCS11 plugin.
* Trustee now parses nested init-data fields into JSON.
* Trustee attestation policy can specify extensions for the attestation token.
* Basic validated identifiers added to default Trustee attestation policy. 
* AMD SNP verifier supports VCEK caching and pre-provisioning.
* Improved support for Trustee and guest-components non-x86 builds.
* Added image pull benchmarking tool to image-rs.
* AAEL (eventlog) now covers pull image events.
* Image signature configuration can be specified directly in CDH config file (and init-data).
* Improvements to image-rs whiteout handling.
* TPM attester improvements.
* Improved error reporting in image-rs.
* Confidential guest kernel bumped to 6.18.
* TDX uses hardened OVMF build (OVMF 202511).
* Improvements to IBM Cloud adaptor 
* Trustee resource policy now has structured data and query parameters. For example, the resource path
  is passed as a list rather than one string.

## Hardware Support

Attestation is supported and tested on three platforms: Intel TDX, AMD SEV-SNP, and IBM SEL.
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.5 LTS
* k8s: v1.33.0 (Kubeadm)
* Kustomize: v5.6.0
* Containerd: v1.7.27

### Intel TDX

* Kernel: 6.8.0-1028-intel (kobuk)
* OS: Ubuntu 24.04 LTS
* k8s: v1.35.0 (Kubeadm)
* Kustomize: v5.3.0

TDX will move away from the kobuk kernel build in the next release in favor of
the upstream 24.04.4 HWE kernel and the QEMU that ships with CoCo.

### IBM Secure Execution for Linux (SEL)

* Hardware: IBM Z16 LPAR
* Kernel: 6.8.0-90-generic
* OS: Ubuntu 24.04.2 LTS
* k8s: v1.34.0 (Kubeadm)
* Kustomize: v5.8.0

### NVIDIA

There are two NVIDIA runners.

* Hardware: Intel(R) Xeon(R) Gold 6354 and NVIDIA Corporation GH100
* Kernel: 6.17.0-8-generic
* OS: Ubuntu 25.10
* k8s: v1.34.3
* Kustomize: v5.7.1
* Containerd: v2.0.4 1a43cb6a1035441f9aca8f5666a9b3ef9e70ab20

* Hardware: AMD EPYC 9274F and NVIDIA Corporation GH100
* Kernel: 6.17.0-7-generic
* OS: Ubuntu 25.10
* k8s: v1.34.1
* Kustomize: v5.7.1
* Containerd: v2.2.0-beta.1 d94e514fc46c2a6ae371c026b234bb5c39194f52

## 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.
  * There is an experimental option to force guest image pull without a snapshotter.
    This is also not mature and must be manually configured.
* 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.
