Skip to content

cca-kata: Small correction fixes #2690

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
anta5010 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

cca-kata: Small correction fixes #2690

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions content/learning-paths/servers-and-cloud-computing/cca-kata/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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/)
Expand Down
8 changes: 4 additions & 4 deletions content/learning-paths/servers-and-cloud-computing/cca-kata/cca-kata.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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.
Expand Down