Run Confidential Containers with encrypted images using Arm CCA and Trustee
Introduction
Overview of Confidential Containers and Arm CCA Attestation with Trustee
Run a confidential container with an encrypted image
Next Steps
Run Confidential Containers with encrypted images using Arm CCA and Trustee
Who is this for?
This Learning Path is for developers who want to understand how Confidential Containers run in Arm CCA Realms.
What will you learn?
Upon completion of this Learning Path, you will be able to:
- 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
Before starting, you will need the following:
- An AArch64 or x86_64 computer running Linux or macOS. Cloud-based instances can also be used; see the Arm cloud service providers
- Completion of the Run an end-to-end Attestation with Arm CCA and Trustee Learning Path
Summary
This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
You’ll deploy a confidential container from an encrypted image inside an Arm CCA Realm on an Armv9-A AEM Base Fixed Virtual Platform (FVP) with Realm Management Extension (RME) support. First, you’ll learn about the Confidential Containers design, understand which components run inside the Trusted Execution Environment, and see how Trustee services use Arm CCA attestation to authorize decryption. Then, you’ll start the Trustee services and a local Docker registry, publish an encrypted image, and launch the container on the FVP. By the end, you’ll confirm attestation, key release, and that the workload runs in a Realm only after authorization.
Frequently asked questions
These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
Confirm that the AS, KBS, and RVPS processes have started and are listening. Check their startup logs for ready or healthy messages before continuing.
Use the local Docker registry started as part of this Learning Path. Tag the encrypted image for that registry and push, and proceed only after the push completes without errors.
The runtime pulls the encrypted image from the local registry, performs Arm CCA attestation via Trustee, obtains decryption keys, and starts the workload inside an Arm CCA Realm. Expect logs indicating successful attestation or authorization and that the container is running.
Follow the verification step to check Realm-specific output from the launch. Validation relies on Trustee accepting CCA attestation evidence; without acceptance, the image remains locked and the workload does not start.
Verify the local registry is running and reachable and that the image was pushed with the expected tag. Confirm AS, KBS, and RVPS are up and that attestation evidence is available so the KBS can release keys after authorization.