From 60765581e3e46b52c6b793271c420e070163a983 Mon Sep 17 00:00:00 2001 From: Madeline Underwood Date: Sat, 10 Jan 2026 23:24:41 +0000 Subject: [PATCH 1/2] Update titles and content for clarity in CCA Learning Path materials --- .../cca-kata/_index.md | 16 +++----- .../cca-kata/cca-kata.md | 39 +++++++------------ .../cca-kata/flow.md | 2 +- 3 files changed, 20 insertions(+), 37 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-kata/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-kata/_index.md index 62768c26d6..af59ff7b50 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-kata/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-kata/_index.md @@ -1,21 +1,17 @@ --- -title: Run Confidential Containers with Encrypted Images using Arm CCA and Trustee +title: Run Confidential Containers with encrypted images using Arm CCA and Trustee -draft: true -cascade: - draft: true - minutes_to_complete: 60 -who_is_this_for: This Learning Path is for software developers who want to understand how Confidential Containers can be run in Arm CCA Realm. +who_is_this_for: This Learning Path is for developers who want to understand how Confidential Containers run in Arm CCA Realms. learning_objectives: - - Gain an overview of Confidential Containers and their role in confidential computing. - - Understand how Trustee services are used with Arm CCA attestation to authorize and unlock confidential workloads. - - Deploy a Confidential Container from an encrypted image inside an Arm CCA Realm using an Armv9-A AEM Base Fixed Virtual Platform (FVP) with RME support. + - Gain an overview of Confidential Containers and their role in confidential computing + - Understand how Trustee services are used with Arm CCA attestation to authorize and unlock confidential workloads + - Deploy a Confidential Container from an encrypted image inside an Arm CCA Realm using an Armv9-A AEM Base Fixed Virtual Platform (FVP) with RME support prerequisites: - - An AArch64 or x86_64 computer running Linux or macOS. Cloud-based instances can also be used; see the [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/). + - An AArch64 or x86_64 computer running Linux or macOS. Cloud-based instances can also be used; see the [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/) - Completion of the ["Run an end-to-end Attestation with Arm CCA and Trustee"](/learning-paths/servers-and-cloud-computing/cca-trustee) Learning Path author: diff --git a/content/learning-paths/servers-and-cloud-computing/cca-kata/cca-kata.md b/content/learning-paths/servers-and-cloud-computing/cca-kata/cca-kata.md index bf47ba9fb7..702747f738 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-kata/cca-kata.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-kata/cca-kata.md @@ -8,19 +8,13 @@ weight: 2 # 1 is first, 2 is second, etc. layout: "learningpathall" --- - ## Confidential Containers -["Confidential Containers"](https://github.com/confidential-containers/confidential-containers) is an open-source community -project focused on enabling cloud native confidential computing by leveraging Trusted Execution Environments (TEEs) to protect container workloads and the data they process. +[Confidential Containers](https://github.com/confidential-containers/confidential-containers) is an open-source community project focused on enabling cloud-native confidential computing by using Trusted Execution Environments (TEEs) to protect container workloads and the data they process. ## Design overview -Confidential computing systems are typically defined by what runs inside the Trusted Execution Environment (TEE) and what remains outside of it. -In the Confidential Containers architecture, the TEE contains: - * The workload pod - * Helper processes and daemons required to support the workload pod. -Everything else outside of the TEE, including the hypervisor, other pods, and the control plane, is considered untrusted. This trust boundary is fundamental to how Confidential Containers protect workload confidentiality. +Confidential computing systems are defined by what runs inside the Trusted Execution Environment (TEE) and what remains outside it. In the Confidential Containers architecture, the TEE contains the workload pod and helper processes required to support it. Everything outside the TEE, including the hypervisor, other pods, and the control plane, is considered untrusted. This trust boundary is fundamental to how Confidential Containers protect workload confidentiality. ### Kata Containers @@ -35,36 +29,29 @@ To enable this, additional components such as **image-rs** are included in the g On the host side, a **nydus snapshotter** intercepts the image pull process and redirects control to **image-rs** running inside the guest. The diagram below illustrates the interaction between **containerd**, the **nydus snapshotter**, and **image-rs**. -![Image pulling alt-text#center](image_pulling.png "Image pulling") +![Diagram showing the image pulling flow: containerd on the host communicates with nydus snapshotter, which redirects the pull request to image-rs running inside the guest VM to retrieve and unpack the container image securely alt-txt#center](image_pulling.png "Image pulling flow") ### Attestation -Confidential Containers also include components that enable attestation, which is a core requirement for confidential computing. -Many guest operations depend on attestation. For example, before an encrypted container image can be unpacked, the guest must prove its identity and integrity in order to retrieve the decryption key. -Inside the guest the Confidential Data Hub (CDH) and Attestation Agent (AA) manage attestation flows and secret handling. -Like image pulling components, these services extend beyond traditional Kata deployments and are part of the Confidential Containers ["guest components"](https://github.com/confidential-containers/guest-components) repository. +Confidential Containers include components that enable attestation, a core requirement for confidential computing. Many guest operations depend on attestation. For example, before an encrypted container image can be unpacked, the guest must prove its identity and integrity to retrieve the decryption key. + +Inside the guest, the Confidential Data Hub (CDH) and Attestation Agent (AA) manage attestation flows and secret handling. Like image pulling components, these services extend beyond traditional Kata deployments and are part of the Confidential Containers [guest components](https://github.com/confidential-containers/guest-components) repository. -The CDH and AA communicate with an external trusted service using the Key Broker Service (KBS) protocol. -Confidential Containers provide [Trustee](https://github.com/confidential-containers/trustee) as an attestation service and key management engine that: - * Verifies the guest Trusted Computing Base (TCB) - * Evaluates attestation evidence - * Releases secrets only when policy requirements are met +The CDH and AA communicate with an external trusted service using the Key Broker Service (KBS) protocol. Confidential Containers provide [Trustee](https://github.com/confidential-containers/trustee) as an attestation service and key management engine that verifies the guest Trusted Computing Base (TCB), evaluates attestation evidence, and releases secrets only when policy requirements are met. The diagram below shows a simplified view of the attestation flow. -![Attestation alt-text#center](attestation.png "Attestation") +![Diagram showing the attestation flow: the Attestation Agent inside the guest VM communicates with Trustee services (KBS, AS, RVPS) on the host to verify the realm's identity and retrieve secrets like decryption keys alt-txt#center](attestation.png "Attestation flow") In this Learning Path, attestation is used to obtain the encryption key required to decrypt a container image. Learn more about how Trustee services are used to evaluate the trustworthiness of a CCA Realm and how attestation policy gates secrets release in the ["Run an end-to-end Attestation with Arm CCA and Trustee"](/learning-paths/servers-and-cloud-computing/cca-trustee) Learning Path. -### Full Architecture Overview - -By combining, Kata Containers, Guest-side image pulling and attestation and secret management, you arrive at the complete Confidential Containers architecture shown below: +### Full architecture overview -![Confidential Containers alt-text#center](confidential_containers.png "Confidential Containers") +By combining Kata Containers, guest-side image pulling, and attestation and secret management, you arrive at the complete Confidential Containers architecture shown below: +![Complete Confidential Containers architecture diagram showing the host environment with containerd, nydus snapshotter, and Trustee services, plus the guest VM running inside an Arm CCA Realm with the Attestation Agent, CDH, and image-rs components that enable secure container deployment#center](confidential_containers.png "Complete Confidential Containers architecture") -For convenience, both the Confidential Containers software stack and Trustee services are packaged as Docker containers. These can be run on any suitable AArch64 or x86_64 development host. -Because the confidential workload itself runs inside an Arm CCA Realm, this Learning Path uses the Arm Fixed Virtual Platform (FVP) along with the Arm CCA reference software stack to provide the required environment. +Both the Confidential Containers software stack and Trustee services are packaged as Docker containers. These can run on any suitable AArch64 or x86_64 development host. Because the confidential workload runs inside an Arm CCA Realm, this Learning Path uses the Arm Fixed Virtual Platform (FVP) along with the Arm CCA reference software stack to provide the required environment. -Proceed to the next section to run a confidential container using the components and architecture described here. +In the next section, you'll run a confidential container using the components and architecture described here. diff --git a/content/learning-paths/servers-and-cloud-computing/cca-kata/flow.md b/content/learning-paths/servers-and-cloud-computing/cca-kata/flow.md index 32b141feec..b455405bc6 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-kata/flow.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-kata/flow.md @@ -1,6 +1,6 @@ --- # User change -title: Run confidential containers with encrypted images using Arm CCA and Trustee +title: Run a confidential container with an encrypted image weight: 3 # 1 is first, 2 is second, etc. From db43fc9f70fbac88ce0fff1d42cb769c135f65cb Mon Sep 17 00:00:00 2001 From: Madeline Underwood Date: Sat, 10 Jan 2026 23:24:52 +0000 Subject: [PATCH 2/2] Update image caption in Confidential Containers architecture diagram for clarity --- .../servers-and-cloud-computing/cca-kata/cca-kata.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-kata/cca-kata.md b/content/learning-paths/servers-and-cloud-computing/cca-kata/cca-kata.md index 702747f738..40e09b0498 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-kata/cca-kata.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-kata/cca-kata.md @@ -50,7 +50,7 @@ Learn more about how Trustee services are used to evaluate the trustworthiness o By combining Kata Containers, guest-side image pulling, and attestation and secret management, you arrive at the complete Confidential Containers architecture shown below: -![Complete Confidential Containers architecture diagram showing the host environment with containerd, nydus snapshotter, and Trustee services, plus the guest VM running inside an Arm CCA Realm with the Attestation Agent, CDH, and image-rs components that enable secure container deployment#center](confidential_containers.png "Complete Confidential Containers architecture") +![Complete Confidential Containers architecture diagram showing the host environment with containerd, nydus snapshotter, and Trustee services, plus the guest VM running inside an Arm CCA Realm with the Attestation Agent, CDH, and image-rs components that enable secure container deployment alt-txt#center](confidential_containers.png "Complete Confidential Containers architecture") Both the Confidential Containers software stack and Trustee services are packaged as Docker containers. These can run on any suitable AArch64 or x86_64 development host. Because the confidential workload runs inside an Arm CCA Realm, this Learning Path uses the Arm Fixed Virtual Platform (FVP) along with the Arm CCA reference software stack to provide the required environment.