From a863c1684c9ff0814aee114aae3089da2ef7a14a Mon Sep 17 00:00:00 2001 From: Anton Antonov Date: Tue, 23 Dec 2025 13:13:46 +0000 Subject: [PATCH] cca-kata: Small correction fixes Signed-off-by: Anton Antonov --- .../servers-and-cloud-computing/cca-kata/_index.md | 4 ++-- .../servers-and-cloud-computing/cca-kata/cca-kata.md | 8 ++++---- 2 files changed, 6 insertions(+), 6 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 0b5152976..cd8c6def1 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 @@ -11,8 +11,8 @@ who_is_this_for: This Learning Path is for software developers who want to under learning_objectives: - Overview of Confidential Containers - - Understand how Trustee services are used for CCA realm attestation to unlock the confidential processing of data. - - Use an encrypted image to deploy a Confidential Containers in a CCA realm on an Armv9-A AEM Base Fixed Virtual Platform (FVP) that has support for RME extensions. + - Understand how Trustee services are used for CCA attestation to unlock the confidential processing of data. + - Use an encrypted image to deploy a Confidential Container in a CCA realm on an Armv9-A AEM Base Fixed Virtual Platform (FVP) that has support for RME extensions. prerequisites: - An AArch64 or x86_64 computer running Linux or macOS; you can use cloud instances - see the [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/) 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 5c16ef27b..cd9e93544 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 @@ -16,9 +16,9 @@ working to enable cloud native confidential computing by leveraging Trusted Exec ## Design overview -Confidential computing projects are largely defined by what is inside the enclave and what is not. -For Confidential Containers, the enclave contains the workload pod and helper processes and daemons that facilitate the workload pod. -Everything else, including the hypervisor, other pods, and the control plane, is outside of the enclave and untrusted. +Confidential computing projects are largely defined by what is inside the Trusted Execution Environment (TEE) and what is not. +For Confidential Containers, the TEE contains the workload pod and helper processes and daemons that facilitate the workload pod. +Everything else, including the hypervisor, other pods, and the control plane, is outside of the TEE and untrusted. ### Kata Containers @@ -46,7 +46,7 @@ This is a simplified diagram showing the interaction of **containerd**, the **ny Confidential Containers also provides components inside the guest and elsewhere to facilitate attestation. Attestation is a crucial part of confidential computing and a direct requirement of many guest operations. For example, to unpack an encrypted container image, the guest must retrieve a secret key. -Inside the guest the **confidential-data-hub** and **attestation-agent** handle operations involving secrets and attestation. +Inside the guest the **Confidential Data Hub (CDH)** and **Attestation Agent (AA)** handle operations involving secrets and attestation. Again, these components are beyond the scope of traditional Kata deployments and are located in the ["guest components"](https://github.com/confidential-containers/guest-components) repository. The CDH and AA use the KBS Protocol to communicate with an external, trusted entity.