Delete .md files associated with trust model

This documentation is being migrated to the website

Signed-off-by: Chris Porter <porter@ibm.com>

.github/ISSUE_TEMPLATE/release-check-list.md

@@ -20,6 +20,7 @@ flowchart LR
     Guest-Components .-> Client-tool
     Guest-Components --> enclave-agent
     enclave-cc --> kustomization.yaml
+    Operator --> versions.yaml
     Guest-Components --> versions.yaml
     Trustee --> versions.yaml
     Kata --> versions.yaml
@@ -47,7 +48,8 @@ flowchart LR
 Starting with v0.9.0 the release process no longer involves centralized dependency management.
 In other words, when doing a CoCo release, we don't push the most recent versions of the subprojects
 into Kata and enclave-cc. Instead, dependencies should be updated during the normal process of development.
-Releases of most subprojects are now decoupled from releases of the CoCo project.
+After the release, we typically cut a release of the subprojects that reflects whatever commit was used
+in the Kata release.
 
 ## The Steps
 
@@ -72,13 +74,9 @@ Identify/create the bundles that we will release for Kata and enclave-cc.
     If you absolutely cannot use a Kata release,
     you can consider releasing one of these bundles.
 
-- [ ] 3. :eyes: **Create a peer pods release**
+### Update the Operator
 
-    Create a peer pods release based on the Kata release, by following the [documented flow](https://github.com/confidential-containers/cloud-api-adaptor/blob/main/docs/Release-Process.md).
+- [ ] 3. :eyes: **Check operator pre-installation and open PR if needed**
-
-### Test Release with Operator
-
-- [ ] 4. :eyes: **Check operator pre-installation and open PR if needed**
     
     The operator uses a pre-install container to setup the node.
     Check that the container matches the dependencies used in Kata
@@ -88,7 +86,7 @@ Identify/create the bundles that we will release for Kata and enclave-cc.
         * Compare the `nydus-snapshotter` version in Kata [versions.yaml](https://github.com/kata-containers/kata-containers/blob/main/versions.yaml) (search for `nydus-snapshotter` and check its `version` field) with the [Makefile](https://github.com/confidential-containers/operator/blob/main/install/pre-install-payload/Makefile) (check the `NYDUS_SNAPSHOTTER_VERSION` value) for the operator pre-install container.
             * **If they do not match, stop and open a PR now. In the PR, update the operator's Makefile to match the version used in kata. After the PR is merged, continue.**
 
-- [ ] 5. :wrench: **Open a PR to the operator to update the release artifacts**
+- [ ] 4. :wrench: **Open a PR to the operator to update the release artifacts**
 
     Update the operator to use the payloads identified in steps 1, 2, 3, and 4.
 
@@ -114,13 +112,39 @@ Identify/create the bundles that we will release for Kata and enclave-cc.
 
 ### Final Touches
 
-- [ ] 6. :trophy: **Cut an operator release using the GitHub release tool**
+- [ ] 5. :trophy: **Cut an operator release using the GitHub release tool**
+
+- [ ] 6. :wrench: **Create a peer pods release**
+
+    Create a peer pods release based on the Kata release, by following the [documented flow](https://github.com/confidential-containers/cloud-api-adaptor/blob/main/docs/Release-Process.md).
 
 - [ ] 7. :green_book: **Make sure to update the [release notes](https://github.com/confidential-containers/confidential-containers/tree/main/releases) and tag/release the confidential-containers repo using the GitHub release tool.**
 
-- [ ] 8. :hammer: **Poke Wainer Moschetta (@wainersm) to update the release to the OperatorHub. Find the documented flow [here](https://github.com/confidential-containers/operator/blob/main/docs/OPERATOR_HUB.md).**
-
 ### Post-release
 
-- [ ] 9. :wrench: **Open a PR to the operator to go back to latest payloads after release**
+- [ ] 8. :wrench: **Open a PR to the operator to go back to latest payloads after release**
     After the release, the operator's payloads need to go back to what they were (e.g. using "latest" instead of a specific commit sha). As an example, the v0.9.0-alpha1 release applied [these changes](https://github.com/confidential-containers/operator/pull/389/files). You should use `git revert -s` for this.
+
+- [ ] 9. :pushpin: **Tag the version of guest-components used in the release**.
+
+    Go look at [versions.yaml](https://github.com/kata-containers/kata-containers/blob/main/versions.yaml)
+    in Kata Containers and find the version of the guest-components that was used in the Kata release.
+    Tag this commit in guest-components with the latest version of guest components.
+    Note that the version of guest-components might not be the same as the version of CoCo.
+
+- [ ] 10. :scissors: **Cut a release of guest-components using GitHub release tool**
+
+- [ ] 11. :pushpin: **Tag the version of Trustee used in the release**
+
+    Follow the same process as step 9 but for Trustee.
+
+- [ ] 12. :scissors: **Cut a release of Trustee using GitHub release tool**
+
+- [ ] 13. :wrench: **Tag the Trustee release images**
+
+    Use the Trustee release helper script to push the CI images corresponding to the released hash
+    as the release images.
+
+- [ ] 14. :pushpin: **Tag the latest version of the website for the release**
+
+    Make sure the website is up-to-date for the latest release, and then tag the repo.

.lycheeignore

@@ -1 +1,2 @@
 https://sigs.centos.org/virt/tdx/
+https://www.intel.com/

ADOPTERS.md

@@ -16,6 +16,8 @@ See list of adopter types at the bottom of this page.
 | [KubeArmor](https://www.kubearmor.io/) | Runtime Security | Beta | Another project | An open source project that leverages CoCo as part of their solution, integrates with for compatibility and interoperability, or is used in the supply chain of another project [(5GSEC)](https://github.com/5GSEC/nimbus/blob/main/examples/clusterscoped/coco-workload-si-sib.yaml). |
 | [Red Hat](https://www.redhat.com/en) | [OpenShift confidential containers](https://www.redhat.com/en/blog/learn-about-confidential-containers) | Beta | Service Provider | Confidential Containers are available from [OpenShift sandboxed containers release version 1.7.0](https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.7/) as a tech preview on Azure cloud for both Intel TDX and AMD SEV-SNP. The tech preview also includes support for confidential containers on IBM Z and LinuxONE using Secure Execution for Linux (IBM SEL).|
 | [ByteDance](https://www.bytedance.com/) | Jeddak Sandbox | Beta | End-User / Service Provider | Jeddak Sandbox leverages CoCo to protect the data privacy in the process of the company's business  (for details chendian.imtyrant@bytedance.com) |
+| [Intel](https://www.intel.com/) | [Enterprise-RAG](https://github.com/opea-project/Enterprise-RAG/blob/main/docs/tdx.md)<br>[OPEA](https://github.com/opea-project/GenAIInfra/tree/main/helm-charts/TDX.md) | Beta | End-User / Service Provider | Intel runs confidential container deployments on Kubernetes with Intel TDX |
+| [Switchboard](https://www.switchboard.xyz/) | [Decentralized Crypto Oracle](https://docs.switchboard.xyz/switchboard-protocol/running-a-switchboard-oracle) | Production | Service Provider | Running our Decentralized Oracles code in CoCo on AMD SEV SNP bare metal machines |
 |TBD| | | | |
 |TBD| | | | |
 

CONTRIBUTING.md

@@ -78,6 +78,8 @@ with the community as early as possible. Consider making an `RFC` issue
 that explains the changes. You might also try to break large contributions
 into smaller steps.
 
+Any new feature must be accompanied by new unit tests.
+
 ### Making a Pull Request
 
 If you aren't familiar with Git or the GitHub PR workflow, take a look at [this section](https://github.com/kata-containers/community/blob/main/CONTRIBUTING.md#github-workflow)

MAINTAINERS

@@ -7,12 +7,11 @@ bpradipt, Pradipta Banerjee, Redhat
 peterzcst, Peter Zhu, Intel
 mythi, Mikko Ylinen, Intel
 magowan, James Magowan, IBM
-fitzthum, Tobin Feldman-Fitzthum, IBM
 jiazhang0, Zhang Jia, Alibaba
 jiangliu, Jiang Liu, Alibaba
-larrydewey, Larry Dewey, AMD
 ryansavino, Ryan Savino, AMD
 sameo, Samuel Ortiz, Rivos
 zvonkok, Zvonko Kaiser, NVIDIA
+fitzthum, Tobin Feldman-Fitzthum, NVIDIA
 vbatts, Vincent Batts, Microsoft
 danmihai1, Dan Mihai, Microsoft

governance.md

@@ -85,18 +85,19 @@ Further, as leaders in the community, the SC members will make themselves famili
 
 The current members of the SC are:
 
-* Larry Dewey (@larrydewey) and Ryan Savino (@ryansavino) - AMD
+* Ryan Savino (@ryansavino) - AMD
 * Jiang Liu (@jiangliu) and Jia Zhang (@jiazhang0) - Alibaba
-* James Magowan (@magowan)  and Tobin Feldman-Fitzthum (@fitzthum) - IBM
+* James Magowan (@magowan) and Nina Goradia (@ninag) - IBM
 * Peter Zhu (@peterzcst) and Mikko Ylinen (@mythi) - Intel
 * Pradipta Banerjee (@bpradipt)  and Ariel Adam (@ariel-adam) - Red Hat
 * Samuel Ortiz (@sameo) - Rivos
-* Zvonko Kaiser (@zvonkok) - NVIDIA
+* Zvonko Kaiser (@zvonkok) and Tobin Feldman-Fitzthum (@fitzthum) - NVIDIA
 * Vincent Batts (@vbatts) and Dan Mihai (@danmihai1) - Microsoft
 
 ### Emeritus Members
 
 * Dan Middleton [dcmiddle](https://github.com/dcmiddle) (he/him)
+* Larry Dewey (@larrydewey) - AMD
 
 #### Selection
 

guides/coco-dev.md

@@ -77,16 +77,13 @@ and confidential hardware.
 
 CoCo has a modular attestation interface and there are a few options for attestation.
 CoCo provides a generic Key Broker Service (KBS) that the rest of this guide will be focused on.
-The SEV runtime class uses `simple-kbs`, which is described in the [SEV guide](../guides/sev.md).
 
 ### Select Runtime Class
 
 To use CoCo with confidential hardware, first switch to the appropriate runtime class.
 TDX has one runtime class, `kata-qemu-tdx`. 
 
-For SEV(-ES) use the `kata-qemu-sev` runtime class and follow the [SEV guide](../guides/sev.md). 
+For SNP, use the `kata-qemu-snp` runtime class and follow the [SNP guide](https://confidentialcontainers.org/docs/examples/snp-container-launch/).
-
-For SNP, use the `kata-qemu-snp` runtime class and follow the [SNP guide](../guides/snp.md).
 
 For `enclave-cc` follow the [enclave-cc guide](../guides/enclave-cc.md).
 

guides/enclave-cc.md

@@ -19,7 +19,7 @@ https://github.com/intel/SGXDataCenterAttestationPrimitives) running on every SG
 ## Configuring enclave-cc custom resource to use a different KBC
 
 **Note** Before configuring KBC, please refer to the
-[guide](../quickstart.md#deploy-and-configure-tenant-side-coco-key-broker-system-cluster) to deploy KBS cluster.
+[guide](coco-dev.md#deploy-and-configure-tenant-side-coco-key-broker-system-cluster) to deploy KBS cluster.
 
 **Note** The KBC configuration changes to the enclave-cc custom resource yaml 
 must be made **before** deploying it. 

guides/ephemeral_storage.md

@@ -47,7 +47,6 @@ spec:
       storage: 1Gi
   storageClassName: open-local-lvm
 ```
-Before deploy the workload, we can follow this [documentation](https://github.com/kata-containers/kata-containers/blob/CCv0/docs/how-to/how-to-build-and-test-ccv0.md) and use [ccv0.sh](https://github.com/kata-containers/kata-containers/blob/CCv0/docs/how-to/ccv0.sh) to enable CoCo console debug(optional, check whether working as expected).
 
 Create the workload:
 ```sh

guides/sev.md

@@ -1,286 +0,0 @@
-# SEV-ES Guide
-
-## Platform Setup
-
-
-> [!WARNING]
->
-> In order to launch SEV or SNP memory encrypted guests, the host must be prepared with a compatible kernel, `6.8.0-rc5-next-20240221-snp-host-cc2568386`. AMD custom changes and required components and repositories will eventually be upstreamed. 
-
-> [Sev-utils](https://github.com/amd/sev-utils/blob/coco-202402240000/docs/snp.md) is an easy way to install the required host kernel, but it will unnecessarily build AMD compatible guest kernel, OVMF, and QEMU components. The additional components can be used with the script utility to test launch and attest a base QEMU SNP guest. However, for the CoCo use case, they are already packaged and delivered with Kata.
-Alternatively, refer to the [AMDESE guide](https://github.com/confidential-containers/amdese-amdsev/tree/amd-snp-202402240000?tab=readme-ov-file#prepare-host) to manually build the host kernel and other components.
-
-## Getting Started
-
-This guide covers platform-specific setup for SEV and walks through the complete flows for the different CoCo use cases:
-
-- [Container Launch with Memory Encryption](#container-launch-with-memory-encryption)
-- [Pre-Attestation Utilizing Signed and Encrypted Images](#pre-attestation-utilizing-signed-and-encrypted-images)
-
-## Container Launch With Memory Encryption
-
-### Launch a Confidential Service 
-
-To launch a container with SEV memory encryption, the SEV runtime class (`kata-qemu-sev`) must be specified as an annotation in the yaml. A base alpine docker container ([Dockerfile](https://github.com/kata-containers/kata-containers/blob/main/tests/integration/kubernetes/runtimeclass_workloads/confidential/unencrypted/Dockerfile)) has been previously built for testing purposes. This image has also been prepared with SSH access and provisioned with a [SSH public key](https://github.com/kata-containers/kata-containers/blob/main/tests/integration/kubernetes/runtimeclass_workloads/confidential/unencrypted/ssh/unencrypted.pub) for validation purposes.
-
-Here is a sample service yaml specifying the SEV runtime class: 
-
-```yaml
-kind: Service
-apiVersion: v1
-metadata:
-  name: "confidential-unencrypted"
-spec:
-  selector:
-    app: "confidential-unencrypted"
-  ports:
-  - port: 22
----
-kind: Deployment
-apiVersion: apps/v1
-metadata:
-  name: "confidential-unencrypted"
-spec:
-  selector:
-    matchLabels:
-      app: "confidential-unencrypted"
-  template:
-    metadata:
-      labels:
-        app: "confidential-unencrypted"
-      annotations:
-        io.containerd.cri.runtime-handler: kata-qemu-sev
-    spec:
-      runtimeClassName: kata-qemu-sev
-      containers:
-      - name: "confidential-unencrypted"
-        image: ghcr.io/kata-containers/test-images:unencrypted-nightly
-        imagePullPolicy: Always
-```
-
-Save the contents of this yaml to a file called `confidential-unencrypted.yaml`.
-
-Start the service:
-
-```shell 
-kubectl apply -f confidential-unencrypted.yaml
-```
-
-Check for errors:
-
-```shell
-kubectl describe pod confidential-unencrypted
-```
-
-If there are no errors in the Events section, then the container has been successfully created with SEV memory encryption.
-
-### Validate SEV Memory Encryption
-
-The container dmesg log can be parsed to indicate that SEV memory encryption is enabled and active. The container image defined in the yaml sample above was built with a predefined key that is authorized for SSH access.
-
-Get the pod IP:
-
-```shell
-pod_ip=$(kubectl get pod -o wide | grep confidential-unencrypted | awk '{print $6;}')
-```
-
-Download and save the [SSH private key](https://github.com/kata-containers/kata-containers/raw/main/tests/integration/kubernetes/runtimeclass_workloads/confidential/unencrypted/ssh/unencrypted) and set the permissions.
-
-```shell
-wget https://github.com/kata-containers/kata-containers/raw/main/tests/integration/kubernetes/runtimeclass_workloads/confidential/unencrypted/ssh/unencrypted -O confidential-image-ssh-key
-
-chmod 600 confidential-image-ssh-key
-```
-
-The following command will run a remote SSH command on the container to check if SEV memory encryption is active:
-
-```shell
-ssh -i confidential-image-ssh-key \
-  -o "StrictHostKeyChecking no" \
-  -t root@${pod_ip} \
-  'dmesg | grep "Memory Encryption Features"'
-```
-
-If SEV is enabled and active, the output should return:
-
-```shell
-[    0.150045] Memory Encryption Features active: AMD SEV
-```
-
-## Create an Encrypted Image
-
-If SSH access to the container is desired, create a keypair:
-
-```shell
-ssh-keygen -t ed25519 -f encrypted-image-tests -P "" -C "" <<< y
-```
-
-The above command will save the keypair in a file named `encrypted-image-tests`.
-
-Here is a sample Dockerfile to create a docker image:
-
-```Dockerfile
-FROM alpine:3.16
-
-# Update and install openssh-server
-RUN apk update && apk upgrade && apk add openssh-server
-
-# Generate container ssh key
-RUN ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -P ""
-
-# A password needs to be set for login to work. An empty password is
-# unproblematic as password-based login to root is not allowed.
-RUN passwd -d root
-
-# Copy the remote generated public key to the container authorized_keys
-# Generate with 'ssh-keygen -t ed25519 -f encrypted-image-tests -P "" -C ""'
-COPY encrypted-image-tests.pub /root/.ssh/authorized_keys
-
-# Entry point - run sshd
-ENTRYPOINT /usr/sbin/sshd -D
-```
-
-Store this `Dockerfile` in the same directory as the `encrypted-image-tests` ssh keypair.
-
-Build image:
-
-```shell
-docker build -t encrypted-image-tests .
-```
-
-Tag and upload this unencrypted docker image to a registry:
-
-```shell
-docker tag encrypted-image-tests:latest [REGISTRY_URL]:unencrypted
-docker push [REGISTRY_URL]:unencrypted
-```
-
-Be sure to replace `[REGISTRY_URL]` with the desired registry URL.
-
-[skopeo](https://github.com/containers/skopeo) is required to encrypt the container image. Follow the instructions here to install `skopeo`:
-
-[skopeo Installation](https://github.com/containers/skopeo/blob/main/install.md)
-
-The Attestation Agent hosts a grpc service to support encrypting the image. Clone the repository:
-
-```shell
-attestation_agent_tag="v0.1.0"
-git clone https://github.com/confidential-containers/attestation-agent.git
-(cd attestation-agent && git checkout -b "branch_${attestation_agent_tag}" "${attestation_agent_tag}")
-```
-
-Run the offline_fs_kbs:
-
-```shell
-(cd attestation-agent/sample_keyprovider/src/enc_mods/offline_fs_kbs \
-&& cargo run --release --features offline_fs_kbs -- --keyprovider_sock 127.0.0.1:50001 &)
-```
-
-Create the Attestation Agent keyprovider:
-
-```shell
-cat > attestation-agent/sample_keyprovider/src/enc_mods/offline_fs_kbs/ocicrypt.conf <<EOF
-{
-  "key-providers": {
-    "attestation-agent": {
-      "grpc": "127.0.0.1:50001"
-}}}
-EOF
-```
-
-Set a desired value for the encryption key that should be a 32-bytes and base64 encoded value:
-
-```shell
-enc_key="RcHGava52DPvj1uoIk/NVDYlwxi0A6yyIZ8ilhEX3X4="
-```
-
-Create a Key file:
-
-```shell
-cat > keys.json <<EOF
-{
-    "key_id1":"${enc_key}"
-}
-EOF
-```
-
-Run skopeo to encrypt the image created in the previous section:
-
-```shell
-sudo OCICRYPT_KEYPROVIDER_CONFIG=$(pwd)/attestation-agent/sample_keyprovider/src/enc_mods/offline_fs_kbs/ocicrypt.conf \
-skopeo copy --insecure-policy \
-docker:[REGISTRY_URL]:unencrypted \
-docker:[REGISTRY_URL]:encrypted \
---encryption-key provider:attestation-agent:$(pwd)/keys.json:key_id1
-```
-
-Again, be sure to replace `[REGISTRY_URL]` with the desired registry URL.
-`--insecure-policy` flag is used to connect to the attestation agent and will not impact the security of the project.
-
-Make sure to use the `docker` prefix in the source and destination URL when running the `skopeo copy` command as demonstrated above.
-Utilizing images via the local `docker-daemon` is known to have issues, and the `skopeo copy` command does not return an adequate error
-response. A remote registry known to support encrypted images like GitHub Container Registry (GHCR) is required.
-
-At this point it is a good idea to inspect the image was really encrypted as skopeo can silently leave it unencrypted. Use
-`skopeo inspect` as shown below to check that the layers MIME types are **application/vnd.oci.image.layer.v1.tar+gzip+encrypted**:
-
-```shell
-skopeo inspect docker-daemon:[REGISTRY_URL]:encrypted
-```
-
-Push the encrypted image to the registry:
-
-```shell
-docker push [REGISTRY_URL]:encrypted
-```
-
-`mysql-client` is required to insert the key into the `simple-kbs` database. `jq` is required to json parse responses on the command line.
-
-* Debian / Ubuntu:
-  
-  ```shell
-  sudo apt install mysql-client jq
-  ```
-
-* CentOS / Fedora / RHEL:
-  
-  ```shell
-  sudo dnf install [ mysql | mariadb | community-mysql ] jq
-  ```
-
-The `mysql-client` package name may differ depending on OS flavor and version.
-
-The `simple-kbs` uses default settings and credentials for the MySQL database. These settings can be changed by the `simple-kbs` administrator and saved into a credential file. For the purposes of this quick start, set them in the environment for use with the MySQL client command line:
-
-```shell
-KBS_DB_USER="kbsuser"
-KBS_DB_PW="kbspassword"
-KBS_DB="simple_kbs"
-KBS_DB_TYPE="mysql"
-```
-
-Retrieve the host address of the MySQL database container:
-
-```shell
-KBS_DB_HOST=$(docker network inspect simple-kbs_default \
-  | jq -r '.[].Containers[] | select(.Name | test("simple-kbs[_-]db.*")).IPv4Address' \
-  | sed "s|/.*$||g")
-```
-
-Add the key to the `simple-kbs` database without any verification policy:
-
-```shell
-mysql -u${KBS_DB_USER} -p${KBS_DB_PW} -h ${KBS_DB_HOST} -D ${KBS_DB} <<EOF
-  REPLACE INTO secrets VALUES (10, 'key_id1', '${enc_key}', NULL);
-  REPLACE INTO keysets VALUES (10, 'KEYSET-1', '["key_id1"]', NULL);
-EOF
-```
-
-The second value in the keysets table (`KEYSET-1`) must match the `guest_pre_attestation_keyset` value specified in the SEV kata configuration file located here:
-
-`/opt/confidential-containers/share/defaults/kata-containers/configuration-qemu-sev.toml`
-
-Return to step [Launch the Pod and Verify SEV Encryption](#launch-the-pod-and-verify-sev-encryption) and finish the remaining process. Make sure to change the `encrypted-image-tests.yaml` to reflect the new `[REGISTRY_URL]`.
-
-To learn more about creating custom policies, see the section on [Creating a simple-kbs Policy to Verify the SEV Firmware Measurement](#creating-a-simple-kbs-policy-to-verify-the-sev-guest-firmware-measurement).
-

guides/snp.md

@@ -1,107 +0,0 @@
-# SNP Guide
-
-## Platform Setup
-
-> [!WARNING]
->
-> In order to launch SEV or SNP memory encrypted guests, the host must be prepared with a compatible kernel, `6.8.0-rc5-next-20240221-snp-host-cc2568386`. AMD custom changes and required components and repositories will eventually be upstreamed. 
-
-> [Sev-utils](https://github.com/amd/sev-utils/blob/coco-202402240000/docs/snp.md) is an easy way to install the required host kernel, but it will unnecessarily build AMD compatible guest kernel, OVMF, and QEMU components. The additional components can be used with the script utility to test launch and attest a base QEMU SNP guest. However, for the CoCo use case, they are already packaged and delivered with Kata.
-
-Alternatively, refer to the [AMDESE guide](https://github.com/confidential-containers/amdese-amdsev/tree/amd-snp-202402240000?tab=readme-ov-file#prepare-host) to manually build the host kernel and other components.
-
-## Getting Started
-
-This guide covers platform-specific setup for SNP and walks through the complete flows for the different CoCo use cases:
-
-- [Container Launch with Memory Encryption](#container-launch-with-memory-encryption)
-
-## Container Launch With Memory Encryption
-
-### Launch a Confidential Service 
-
-To launch a container with SNP memory encryption, the SNP runtime class (`kata-qemu-snp`) must be specified as an annotation in the yaml. A base alpine docker container ([Dockerfile](https://github.com/kata-containers/kata-containers/blob/main/tests/integration/kubernetes/runtimeclass_workloads/confidential/unencrypted/Dockerfile)) has been previously built for testing purposes. This image has also been prepared with SSH access and provisioned with a [SSH public key](https://github.com/kata-containers/kata-containers/blob/main/tests/integration/kubernetes/runtimeclass_workloads/confidential/unencrypted/ssh/unencrypted.pub) for validation purposes.
-
-Here is a sample service yaml specifying the SNP runtime class: 
-
-```yaml
-kind: Service
-apiVersion: v1
-metadata:
-  name: "confidential-unencrypted"
-spec:
-  selector:
-    app: "confidential-unencrypted"
-  ports:
-  - port: 22
----
-kind: Deployment
-apiVersion: apps/v1
-metadata:
-  name: "confidential-unencrypted"
-spec:
-  selector:
-    matchLabels:
-      app: "confidential-unencrypted"
-  template:
-    metadata:
-      labels:
-        app: "confidential-unencrypted"
-       annotations:
-        io.containerd.cri.runtime-handler: kata-qemu-snp
-    spec:
-      runtimeClassName: kata-qemu-snp
-      containers:
-      - name: "confidential-unencrypted"
-        image: ghcr.io/kata-containers/test-images:unencrypted-nightly
-        imagePullPolicy: Always
-```
-
-Save the contents of this yaml to a file called `confidential-unencrypted.yaml`.
-
-Start the service:
- 
-```shell
-kubectl apply -f confidential-unencrypted.yaml
-```
-
-Check for errors:
-
-```shell
-kubectl describe pod confidential-unencrypted
-```
-
-If there are no errors in the Events section, then the container has been successfully created with SNP memory encryption.
-
-### Validate SNP Memory Encryption
-
-The container dmesg log can be parsed to indicate that SNP memory encryption is enabled and active. The container image defined in the yaml sample above was built with a predefined key that is authorized for SSH access.
-
-Get the pod IP:
-
-```shell
-pod_ip=$(kubectl get pod -o wide | grep confidential-unencrypted | awk '{print $6;}')
-```
-
-Download and save the SSH private key and set the permissions.
-
-```shell
-wget https://github.com/kata-containers/kata-containers/raw/main/tests/integration/kubernetes/runtimeclass_workloads/confidential/unencrypted/ssh/unencrypted -O confidential-image-ssh-key
-
-chmod 600 confidential-image-ssh-key
-```
-
-The following command will run a remote SSH command on the container to check if SNP memory encryption is active:
-
-```shell
-ssh -i confidential-image-ssh-key \
-  -o "StrictHostKeyChecking no" \
-  -t root@${pod_ip} \
-  'dmesg | grep "Memory Encryption Features""'
-```
-
-If SNP is enabled and active, the output should return:
-
-```shell
-[    0.150045] Memory Encryption Features active: AMD SNP
-```

quickstart.md

@@ -22,7 +22,7 @@ hardware support and limitations.
 You can enable Confidential Containers in an existing Kubernetes cluster using the Confidential Containers Operator.
 When installation is finished, your cluster will have new runtime classes for different hardware platforms,
 including a generic runtime for testing CoCo without confidential hardware support, a runtime using a remote hypervisor
-that allows for cloud integration, a runtime for process-based isolation using SGX, as well as runtimes for TDX and SEV.
+that allows for cloud integration, a runtime for process-based isolation using SGX, as well as runtimes for TDX and SNP.
 
 ## Prerequisites
 
@@ -148,7 +148,6 @@ Details on each of the runtime classes:
 - *kata-clh* - standard kata runtime using the cloud hypervisor 
 - *kata-qemu* - same as kata
 - *kata-qemu-coco-dev* - standard kata runtime using the QEMU hypervisor including all CoCo building blocks for a non CC HW
-- *kata-qemu-sev* - using QEMU, and support for AMD SEV HW
 - *kata-qemu-snp* - using QEMU, and support for AMD SNP HW
 - *kata-qemu-tdx* -using QEMU, and support Intel TDX HW based on what's provided by [Ubuntu](https://github.com/canonical/tdx) and [CentOS 9 Stream](https://sigs.centos.org/virt/tdx/).
 
@@ -202,8 +201,7 @@ With some TEEs, the CoCo use cases and/or configurations are implemented differe
 [guide](./guides) section. To get started using CoCo without TEE hardware, follow the CoCo-dev guide below:
 
 - [CoCo-dev](./guides/coco-dev.md)
-- [SEV(-ES)](./guides/sev.md)
+- [SNP](https://confidentialcontainers.org/docs/getting-started/prerequisites/hardware/snp/)
-- [SNP](./guides/snp.md)
 - TDX: No additional steps required.
 - [SGX](./guides/enclave-cc.md)
 - [IBM Secure Execution](./guides/ibm-se.md)

releases/v0.13.0.md

@@ -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

releases/v0.14.0.md

@@ -0,0 +1,89 @@
+# Release Notes for v0.14.0
+
+Release Date: May 23rd, 2025
+
+This release is based on [3.17.0](https://github.com/kata-containers/kata-containers/releases/tag/3.17.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
+
+* Init-data is supported on bare metal Confidential Containers (see limitations below)
+* [Peer Pods](https://github.com/confidential-containers/cloud-api-adaptor) is now supported by [Alibaba Cloud](https://github.com/confidential-containers/cloud-api-adaptor/tree/main/src/cloud-api-adaptor/alibabacloud).
+* Image-rs supports registry configuration file for fine-grained proxying and remapping of container registries.
+* KBS Client can be used to set reference values for Trustee.
+* KBS Client has a few simple resource policies built-in.
+* Trustee supports native verification of CCA guests in addition to verification via veraison.
+* Trustee artifacts are built and tested for ARM.
+* Trustee can extract reference values from TCG RIMs.
+* Trustee can be configured to support a larger payload size to accomodate guests with large evidence.
+* The confidential guest kernel configuration disables virtio MMIO transport and rng to reduce host attack surface.
+
+## Bug Fixes
+* CDH configuration file no longer requires `coco_as` and `kbs_token` fields to be set when not in use.
+* Trustee with docker compose can attest TDX evidence without any changes to QCNL configuration.
+* Trustee no longer errors when parsing the CCEl of a guest booted with grub. 
+* Trustee default policy matches parsed claims generated by SNP verifier.
+* Trustee k8s deployment and Kata tests updated for new AKS interfaces
+
+## 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](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.
+
+* Bare metal initdata is only tested on TDX and non-tee.
+* Plaintext initdata is not forwarded to Trustee.
+* 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

releases/v0.15.0.md

@@ -0,0 +1,88 @@
+# 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](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.
+
+## CVE Fixes
+
+None

releases/v0.16.0.md

@@ -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.

threats_overview.md

@@ -1,6 +0,0 @@
-# Threat Vectors/Profiles
-
-Links to further documentation detailing specific threats and how Confidential Containers uses
-the trust concepts described in the context of the [Trust Model](./trust_model.md) will be added here.
-
-Current TODO List for Threats to be covered is tracked under Issues [#2](https://github.com/confidential-containers/documentation/issues/29)

trust_model.md

@@ -1,115 +0,0 @@
-# Trust Model for Confidential Containers
-A clear definition of trust for the confidential containers project is needed to ensure the
-components and architecture deliver the security principles expected for cloud native
-confidential computing. It provides the solid foundations and unifying security principles
-against which we can assess architecture and implementation ideas and discussions.
-
-## Trust Model Definition
-The [Trust Modeling for Security Architecture Development article](https://www.informit.com/articles/article.aspx?p=31546)
-defines Trust Modeling as :
-
->    A trust model identifies the specific mechanisms that are necessary to respond to a specific
->    threat profile.
-
->    A trust model must include implicit or explicit validation of an entity's identity or the
->    characteristics necessary for a particular event or transaction to occur.
-
-## Trust Boundary
- The trust model also helps determine the location and direction of the trust boundaries where a
-[trust boundary](https://en.wikipedia.org/wiki/Trust_boundary) describes a location where
- program data or execution changes its level of "trust", or where two principals with different
- capabilities exchange data or commands. Specific to Confidential Containers is the trust
- boundary that corresponds to the boundary of the Trusted Execution Environment (TEE). The TEE
- side of the trust boundary will be hardened to prevent the violation of the trust
- boundary.
-
-## Required Documentation
-In order to describe and understand particular threats we need to establish trust boundaries and
-trust models relating to the key aspects, components and actors involved in Cloud Native
-Confidential Computing. We explore trust using different orthogonal ways of considering cloud
-native approaches when they use an underlying TEE technology and
-identifying where there may be considerations to preserve the value of using a TEE.
-
-### Trust Model Considerations
-- [Personas](./trust_model_personas.md)
-
-Further documentation will highlight specific [threat vectors](./threats_overview.md) in detail,
-considering risk,
-impact, mitigation etc as the project progresses. The Security Assurance section, Page 31, of
-Cloud Native Computing Foundation (CNCF)
-[Cloud Native Security Paper](https://github.com/cncf/tag-security/blob/3e57e7c472f7053c693292281419ab926155fe2d/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf)
- will guide this more detailed threat vector effort.
-
-### Related Prior Effort
-
-Confidential Containers brings confidential computing into a cloud native context and should
-therefore refer to and build on trust and security models already defined.
-
-For example:
-
-- Confidential Computing Consortium (CCC) published
-  "[A Technical Analysis of Confidential Computing](https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.3_unlocked.pdf)"
-  section 5 of which defines the threat model for confidential computing.
-- CNCF Security Technical Advisory Group published
-  "[Cloud Native Security Whitepaper](https://github.com/cncf/tag-security/blob/3e57e7c472f7053c693292281419ab926155fe2d/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf)"
-- Kubernetes provides documentation :
-  "[Overview of Cloud Native Security](https://kubernetes.io/docs/concepts/security/overview/)"
-- Open Web Application Security Project -
-  "[Docker Security Threat Modeling](https://github.com/OWASP/Docker-Security/blob/main/001%20-%20Threats.md)"
-
-The commonality between confidential containers project and confidential computing is to reduce
-the ability for unauthorised access to data and code inside TEEs sufficiently such that this path
-is not an economically or logically viable attack during execution (5.1 Goal within the CCC
-publication
-[A Technical Analysis of Confidential Computing](https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.3_unlocked.pdf)).
-
-This means our trust and threat modelling should
-- Focus on which aspects of code and data have integrity and/or confidentiality protections.
-- Focus on enhancing existing Cloud Native models in the context of exploiting TEEs.
-- Consider existing Cloud Native technologies and the role they can play for confidential containers.
-- Consider additional technologies to fulfil a role in Cloud Native exploitation of TEEs.
-
-## Illustration
-
-The following diagram shows which components in a Confidential Containers setup
-are part of the TEE (green boxes labeled TEE). The hardware and guest work in
-tandem to establish a TEE for the pod, which provides the isolation and
-integrity protection for data in use.
-
-![Threat model](./images/coco-threat-model.png)
-
-Not depicted: Process-based isolation from the enclave-cc runtime class. That isolation model further removes the guest operating system from the trust boundary. See the enclave-cc sub-project for more details:
-https://github.com/confidential-containers/enclave-cc/
-
-Untrusted components include:
-1. The host operating system, including its hypervisor, KVM
-2. Other Cloud Provider host software beyond the host OS and hypervisor
-3. Other virtual machines (and their processes) resident on the same host
-4. Any other processes on the host machine (including the kubernetes control plane).
-
-## Out of Scope
-
-The following items are considered out-of-scope for the trust/threat modelling within confidential
-containers :
-
-- Vulnerabilities within the application/code which has been requested to run inside a TEE.
-- Availability part of the Confidentiality/Integrity/Availability in CIA Triad.
-- Software TEEs. At this time we are focused on hardware TEEs.
-- Certain security guarantees are defined by the underlying TEE and these
-  may vary between TEEs and generations of the same TEE. We take these guarantees at face value
-  and will only highlight them where they become relevant to the trust model or threats we
-  consider.
-
-## Summary
-
-In practice, those deploying workloads into TEE environments may have varying levels of trust
-in the personas who have privileges regarding orchestration or hosting the workload. This trust
-may be based on factors such as the relationship with the owner or operator of the host, the
-software and hardware it comprises, and the likelihood of physical, software, or  social
-engineering compromise.
-
-Confidential containers will have specific focus on preventing potential security threats at
-the TEE boundary and ensure privileges which are accepted within cloud native environment as
-crossing the boundary are mitigated from threats within the boundary. We cannot allow the
-security of the TEE to be under control of operations outside the TEE or from areas not trusted
-by the TEE.

trust_model_personas.md

@@ -1,199 +0,0 @@
-# Trust Model Considerations - Personas
-
-## Personas
-Otherwise referred to as actors or agents, these are individuals or groups capable of
-carrying out a particular threat.
-In identifying personas we consider :
-- The Runtime Environment, Figure 5, Page 19 of CNCF
-  [Cloud Native Security Paper](https://github.com/cncf/tag-security/blob/3e57e7c472f7053c693292281419ab926155fe2d/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf).
-  This highlights three layers, Cloud/Environment, Workload Orchestration, Application.
-- The Kubernetes
-  [Overview of Cloud Native Security](https://kubernetes.io/docs/concepts/security/overview/)
-  identifies the 4C's of Cloud Native
-  Security as Cloud, Cluster, Container and Code. However data is core to confidential
-  containers rather than code.
-- The Confidential Computing Consortium paper
-  [A Technical Analysis of Confidential Computing](https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.3_unlocked.pdf)
- defines Confidential Computing as the protection of data in use by performing computations in a
-  hardware-based Trusted Execution Environment (TEE).
-
-In considering personas we recognise that a trust boundary exists between each persona and we
-explore how the least privilege principle (as described on Page 40 of
-  [Cloud Native Security Paper](https://github.com/cncf/tag-security/blob/3e57e7c472f7053c693292281419ab926155fe2d/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf)
-) should apply to any actions which cross these boundaries.
-
- Confidential containers can provide enhancements to ensure that the expected code/containers
- are the only code that can operate over the data. However any vulnerabilities within this code
- are not mitigated by using confidential containers, the Cloud Native Security Whitepaper
- details Lifecycle aspects that relate to the security of the code being placed into containers
- such as Static/Dynamic Analysis, Security Tests, Code Review etc which must still be followed.
-
-![Personas Model](./images/persona_model.svg)
-
-Any of these personas could attempt to perform malicious actions:
-
-### Infrastructure Operator
-This persona has privileges within the Cloud Infrastructure which includes the hardware and
-firmware used to provide compute, network and storage to the Cloud Native solution.
-They are responsible for availability of infrastructure used by the cloud native environment.
-- Have access to the physical hardware.
-- Have access to the processes involved in the deployment of compute/storage/memory used by any
-  orchestration components and by the workload.
-- Have control over TEE hardware availability/type.
-- Responsibility for applying firmware updates to infrastructure including the TEE Technology.
-
-Example : Cloud Service Provider (CSP), Infrastructure as a Service (IaaS), Site Reliability Engineer, etc.
-(SRE)
-
-### Orchestration Operator
-This persona has privileges within the Orchestration/Cluster.
-They are responsible for deploying a solution into a particular cloud native environment and
-managing the orchestration environment.
-For managed cluster this would also include the administration of the cluster control plane.
-- Control availability of service.
-- Control webhooks and deployment of workloads.
-- Control availability of cluster resources (data/networking/storage) and cluster
-  services (Logging/Monitoring/Load Balancing) for the workloads.
-- Control the deployment of runtime artifacts initially required by the TEE during
-  initialisation.
- These boot images once initialised will receive the workload.
-
-Example : A kubernetes administrator responsible for deploying pods to a cluster and
-maintaining the cluster.
-
-### Workload Provider
-This persona designs and creates the orchestration objects comprising the solution (e.g.
-kubernetes pod descriptions etc). These objects reference containers published by Container Image Providers.
-In some cases the Workload and Container Image Providers may be the same entity.
-The solution defined is intended to provide the Application or Workload which in turn provides
-value to the data owners (customers and clients).
-The workload provider and data owner could be part of same company/organisation but
-following the least privilege principle the workload provider should not be able to view or
-manipulate end user data without informed consent.
-- Need to prove to customer aspects of compliance.
-- Defines what the solution requires in order to run and maintain compliance (resources, utility
-  containers/services,  storage).
-- Chooses the method of verifying the container images (from those supported by Container Image
-  Provider) and obtains artifacts needed to allow verification to be completed within
-  the TEE.
-- Provide the boot images initially required by the TEE during
-  initialisation or designates a trusted party to do so.
-- Provide the attestation verification service, or designate a trusted party to provide the
-  attestation verification service.
-
-Example : 3rd party software vendor, cloud solution provider
-
-### Container Image Provider
-
-This persona is responsible for the part of the supply chain that builds container images and
-provides them for use by the solution. Since a workload can
-be composed of multiple containers, there may be multiple container image providers, some
-will be closely connected to the workload provider (business logic containers), others more
-independent to the workload provider (side car containers). The container image provider is expected
-to use a mechanism to allow provenance of container image to be established when a
-workload pulls in these images at deployment time. This can take the form of signing or encrypting
-the container images.
-- Builds container images.
-- Owner of business logic containers. These may contain proprietary algorithms, models or secrets.
-- Signs or encrypts the images.
-- Defines the methods available for verifying the container images to be used.
-- Publishes the signature verification key (public key).
-- Provides any decryption keys through a secure channel (generally to a key management system
-  controlled by a Key Broker Service).
-- Provides other required verification artifacts (secure channel may be considered).
-- Protects the keys used to sign or encrypt the container images.
-
-It is recognised that hybrid options exist surrounding workload provider and container provider.
-For example the workload provider may choose to protect their supply chain by
-signing/encrypting their own container images after following the build patterns already
-established by the container image provider.
-
-Example : Sidecar Container Provider
-
-
-### Data Owner
-Owner of data used, and manipulated by the application.
-- Concerned with visibility and integrity of their data.
-- Concerned with compliance and protection of their data.
-- Uses and shares data with solutions.
-- Wishes to ensure no visibility or manipulation of data is possible by
-  Orchestration Operator or Cloud Operator personas.
-
-## Discussion
-
-### Data Owner vs. All Other Personas
-
-The key trust relationship here is between the Data Owner and the other personas. The Data Owner
-trusts the code in the form of container images chosen by the Workload Provider to operate across
-their data, however they do not trust the Orchestration Operator or Cloud Operator with their
-data and wish to ensure data confidentiality.
-
-
-### Workload Provider vs. Container Image Provider
-
-The Workload Provider is free to choose Container Image Providers that will provide not only
-the images they need but also support the verification method they require.  A key aspect to this
-relationship is the Workload Provider applying Supply Chain
-Security practices (as
-described on Page 42 of
-[Cloud Native Security Paper](https://github.com/cncf/tag-security/blob/3e57e7c472f7053c693292281419ab926155fe2d/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf)
-) when considering Container
-Image Providers. So the Container Image Provider must support the Workload Providers
-ability to provide assurance to the Data Owner regarding integrity of the code.
-
-With Confidential Containers we match the TEE boundary to the most restrictive boundary which is
-between the Workload Provider and the Orchestration Operator.
-
-### Orchestration Operator vs. Infrastructure Operator
-
-Outside the TEE we distinguish between the Orchestration Operator and the Infrastructure
-Operator due to nature of how they can impact the TEE and the concerns of Workload Provider and
-Data Owner. Direct threats exist from the Orchestration Operator as some orchestration actions
-must be permitted to cross the TEE boundary otherwise orchestration cannot occur. A key goal is to
-*deprivilege orchestration* and restrict the
-Orchestration Operators privileges across the boundary. However indirect threats exist
-from the Infrastructure Operator who would not be permitted to exercise orchestration APIs but
-could exploit the low level hardware or firmware capabilities to access or impact the  contents
-of a TEE.
-
-### Workload Provider vs. Data Owner
-
-Inside the TEE we need to be able to distinguish between the Workload Provider and Data Owner in recognition that
-the same workload (or parts such as logging/monitoring etc) can be re-used with different data
-sets to provide a service/solution. In the case of bespoke workload, the workload provider and
-Data Owner may be the same persona. As mentioned the Data Owner must have a level of
-trust in the Workload Provider to use and expose the data provided in an expected and approved
-manner. Page 10 of [A Technical Analysis of Confidential Computing](https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.3_unlocked.pdf)
-, suggests some approaches to establish trust between them.
-
-The TEE boundary allows the introduction of secrets but just as we recognised the
-TEE does not provide protection from code vulnerabilities, we also recognised that a TEE cannot
-enforce complete distrust between Workload Provider and Data Owner. This means secrets within
-the TEE are at risk from both Workload Provider and Data Owner and trying to keep secrets
-which protect the workload (container encryption etc), separated from secrets to protect the
-data (data encryption) is not provided simply by using a TEE.
-
-Recognising that Data Owner and Workload Provider are separate personas helps us to
-identify threats to both data and workload independently and to recognise that any solution must
-consider the potential independent nature of these personas.
-Two examples of trust between Data Owner and Workload Provider are :
-- AI Models which are proprietary and protected requires the workload to be encrypted and not
-  shared with the Data Owner. In this case secrets private to the Workload Provider are needed
-  to access the workload, secrets requiring access to the data are provided by the Data Owner
-  while trusting the workload/model without having direct access to how the workload functions.
-  The Data Owner completely trusts the workload and Workload Provider, whereas the Workload
-  Provider does not trust the Data Owner with the full details of their workload.
-- Data Owner verifies and approves certain versions of a workload, the workload provides the
-  data owner with secrets in order to fulfil this. These secrets are available in the TEE for
-  use by the Data Owner to verify the workload, once achieved the data owner will then provide
-  secrets and data into the TEE for use by the workload in full confidence of what the workload
-  will do with their data. The Data Owner will independently verify versions of the workload and
-  will only trust specific versions of the workload with the data whereas the Workload Provider
-  completely trusts the Data Owner.
-
-### Data Owner vs. End User
-We do not draw a distinction between data owner and end user though we do recognise that in
-some cases these may not be identical. For example data may be provided to a workload to allow
-analysis and results to be made available to an end user. The original data is never provided
-directly to the end user but the derived data is, in this case the data owner can be different
-from the end user and may wish to protect this data from the end user.