# Release Notes for v0.15.0

Release Date: July 23rd, 2025

This release is based on [3.19.1](https://github.com/kata-containers/kata-containers/releases/tag/3.19.1) 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.


## What's New

* Attestation can account for confidential devices attached to a guest in addition to the CPU.
  So far only one confidential device is supported (the Deep Computing Unit from Hygon),
  but more are coming soon.
* The full (plaintext) Init-Data is transmitted to Trustee where it is provided as input
  to the KBS policy. This allows KBS policies to check configuration fields in the Init-Data.
* The image-rs registry config file can be specified directly in the CDH config, allowing it
  to be provisioned via Init-Data.
* Trustee has Prometheus support, allowing admins to track attestation metrics. 
* Trustee can store resources with HashiCorp Vault.
* Trustee can be configured to allow cross-origin requests, such as from browser-based tools.
* Trustee supports reference values of any type that can be represented as JSON including
  complex types like maps and lists.
* The KBS-Client can be used to set reference values of multiple types using the KBS admin
  interface.
* Trustee has more sophisticated [CC eventlog](https://uefi.org/specs/UEFI/2.11/38_Confidential_Computing.html#virtual-platform-cc-event-log) parsing, allowing boot information to be parsed into TCB claims.
* When using Trustee with Docker compose, the required admin keypair is automatically generated. 
* Trustee can attest SNP guests on Milan, Genoa, and Turin hosts with report version 3 or 4.

## 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-1022-intel (kobuk)
* 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.

## CVE Fixes

None
