|
| 1 | +--- |
| 2 | +# User change |
| 3 | +title: "Overview of Confidential Containers and Arm CCA Attestation with Trustee" |
| 4 | + |
| 5 | +weight: 2 # 1 is first, 2 is second, etc. |
| 6 | + |
| 7 | +# Do not modify these elements |
| 8 | +layout: "learningpathall" |
| 9 | +--- |
| 10 | + |
| 11 | + |
| 12 | +## Confidentail Containers |
| 13 | + |
| 14 | +["Confidential Containers"](https://github.com/confidential-containers/confidential-containers) is an open source community |
| 15 | +working to enable cloud native confidential computing by leveraging Trusted Execution Environments to protect containers and data. |
| 16 | + |
| 17 | +## Design overview |
| 18 | + |
| 19 | +Confidential computing projects are largely defined by what is inside the enclave and what is not. |
| 20 | +For Confidential Containers, the enclave contains the workload pod and helper processes and daemons that facilitate the workload pod. |
| 21 | +Everything else, including the hypervisor, other pods, and the control plane, is outside of the enclave and untrusted. |
| 22 | + |
| 23 | +### Kata Containers |
| 24 | + |
| 25 | +Confidential Containers and ["Kata Containers"](https://github.com/kata-containers/kata-containers) are closely linked, |
| 26 | +but the relationship might not be obvious at first. Kata Containers is an existing open source project that encapsulates pods inside of VMs and |
| 27 | +VMs can be run in TEEs. In this Learning Path the guest VM will be run in an ARM CCA realm and you will be able to confirm it by checking kernel messages. |
| 28 | + |
| 29 | +Given the pod-centric design of Confidential Containers this is a perfect match. But if Kata runs pods inside of VM, |
| 30 | +why do we need the Confidential Containers project at all? There are crucial changes needed on top of Kata Containers to preserve confidentiality. |
| 31 | + |
| 32 | +### Image Pulling |
| 33 | + |
| 34 | +When using Kata Containers container images are pulled on the worker node with the help of a CRI runtime like **containerd**. |
| 35 | +The images are exposed to the guest via filesystem passthrough. This is not suitable for confidential workloads |
| 36 | +because the container images are exposed to the untrusted host. With Confidential Containers images are pulled and unpacked inside of the guest. |
| 37 | +This requires additional components such as **image-rs** to be part of the guest rootfs. These components are beyond the scope of |
| 38 | +traditional Kata deployments and live in the Confidential Containers ["guest components"](https://github.com/confidential-containers/guest-components) repository. |
| 39 | + |
| 40 | +On the host, a **nydus snapshotter** is used to pre-empt image pull and divert control flow to **image-rs** inside the guest. |
| 41 | +This is a simplified diagram showing the interaction of **containerd**, the **nydus snapshotter**, and **image-rs**. |
| 42 | + |
| 43 | + |
| 44 | +### Attestation |
| 45 | + |
| 46 | +Confidential Containers also provides components inside the guest and elsewhere to facilitate attestation. |
| 47 | +Attestation is a crucial part of confidential computing and a direct requirement of many guest operations. |
| 48 | +For example, to unpack an encrypted container image, the guest must retrieve a secret key. |
| 49 | +Inside the guest the **confidential-data-hub** and **attestation-agent** handle operations involving secrets and attestation. |
| 50 | +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. |
| 51 | + |
| 52 | +The CDH and AA use the KBS Protocol to communicate with an external, trusted entity. |
| 53 | +Confidential Containers provides [Trustee](https://github.com/confidential-containers/trustee) as an attestation service and key management engine that validates the guest TCB and releases secret resources. |
| 54 | + |
| 55 | +This is a simplified diagram of the attestation process |
| 56 | + |
| 57 | + |
| 58 | +In this Learnig Path the attestation process will be used to obtain an encryption key required to decrypt a container image. |
| 59 | +Learn more about how Trustee services are used to evaluate the trustworthiness of a CCA realm and how attestation policy gates secrets release in |
| 60 | +["Run an end-to-end Attestation with Arm CCA and Trustee"](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-trustee) |
| 61 | + |
| 62 | +### Full diagram |
| 63 | + |
| 64 | +If we take Kata Containers and add guest image pulling and attestation, we arrive at the following diagram, which represents Confidential Containers. |
| 65 | + |
| 66 | + |
| 67 | + |
| 68 | +For convenience, Trustee services and the Confidential Containers software are packaged in Docker containers, |
| 69 | +which you can run on any suitable AArch64 or x86_64 development host. |
| 70 | +Because the client runs in a realm, it uses the Fixed Virtual Platform (FVP) and the reference software stack for Arm CCA. |
| 71 | + |
| 72 | +Proceed to the next section to run a confidential container using the components and architecture described here. |
0 commit comments