release: add release notes for v0.12.0

We picked up some nice features from Trustee in this release as well as
a few other changes.

Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>

releases/v0.12.0.md

@@ -0,0 +1,94 @@
+# Release Notes for v0.12.0
+
+Release Date: January 24th, 2025
+
+This release is based on [3.13.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.
+
+Please see the [quickstart guide](https://confidentialcontainers.org/docs/getting-started/) for details on how to try out Confidential
+Containers.
+
+Note that there have been a few breaking changes in the configuration for Trustee.
+If you have been using a custom configuration based on a previous release,
+you may need to update it.
+
+Please refer to our [Acronyms](https://github.com/confidential-containers/documentation/wiki/Acronyms)
+and [Glossary](https://github.com/confidential-containers/documentation/wiki/Glossary) pages for
+definitions of the acronyms used in this document.
+
+## What's new
+
+* Trustee can produce EAR attestation tokens.
+* Plugin architecture added to Trustee including a PKCS11 plugin
+* Trustee can automatically pull VCEK from KDS when validating AMD SNP evidence.
+* Trustee ITA config allows users to select which policies are evaluated and will now always return a token by default.
+* Sealed secrets can be exposed as volumes more flexibly.
+* Confidential Containers documentation has moved to [website](https://confidentialcontainers.org).
+* The confidential guest kernel was updated to Linux 6.12 LTS adding efistub TDX RTMR measurements of the kernel command line and initrd.
+* For peer pods, fedora-based podvm images build with mkosi are now tested and published
+* CRI-O container runtime is tested for peer pods
+
+
+## Hardware Support
+
+Attestation is supported and tested on three platforms: Intel TDX, AMD SEV-SNP, and IBM SE.
+Not all feature 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.8.0-rc5-next-20240221-snp-host-cc2568386](https://github.com/confidential-containers/linux/tree/amd-snp-host-202402240000)
+* 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 known limitations of this release:
+
+* SEV(-ES) does not support attestation.
+* 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.
+* Image-rs fails to observe container whiteout files in some cases. [Issue](https://github.com/confidential-containers/guest-components/issues/876)
+* 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/community/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.
+* Container logs may be visible to the host and blocking the logs agent endpoint can lead to container deadlocks. [Issue](https://github.com/kata-containers/kata-containers/issues/10680)
+
+## CVE Fixes
+
+None