Deploy confidential containers with CAA
The Cloud API Adaptor (CAA) solution, built on Intel® Trust Domain Extensions (TDX), lets you deploy confidential computing workloads in an ACK cluster for scenarios such as financial risk control and healthcare. It protects sensitive data from external attacks and potential cloud provider threats, helping meet industry compliance requirements.
Intel® TDX is a CPU hardware-based protection technology for Elastic Compute Service (ECS). For more information, see Introduction to TDX.
How it works
CAA (Cloud API Adaptor), also known as Peer Pods, is a core component of the CNCF Confidential Containers project. It calls cloud platform APIs to automatically create confidential virtual machines in a Kubernetes cluster. Workload pods run inside these virtual machines, and the Trusted Execution Environment (TEE) technology of the underlying hardware protects their runtime data. CAA offers the following advantages:
Easy to use: You do not need to maintain the underlying bare-metal architecture or nested virtualization stack. After you connect to an ACK cluster, deploy confidential computing workloads with
kubectlcommands.Secure and confidential: Workloads run in ECS confidential virtual machines, where hardware-level memory encryption and isolation mechanisms ensure the integrity and confidentiality of runtime data.
Open-source compatible: ACK works with the Confidential Containers community to deploy confidential computing workloads in clusters based on the CAA solution, and undergoes continuous community auditing through code transparency.
In an ACK cluster, you deploy the CAA DaemonSet (official version v0.22.0) and then deploy confidential computing workloads. The workloads are created as pods and run inside confidential virtual machines. The hardware protects their runtime data throughout the container lifecycle and helps prevent attacks from outside the virtual machine. The following diagram shows the process.
Prerequisites
The TDX confidential computing environment has some known limitations. Ensure you understand these limitations before you begin.
You have created an ACK managed Pro cluster that meets the following requirements. For more information, see Create an ACK managed cluster.
Parameter
Description
Region and zone
Only the China (Beijing), China (Hangzhou), China (Hong Kong), and Singapore regions are supported.
To create a vSwitch, see Create and manage vSwitches.
Kubernetes version
1.34 or later.
To upgrade your cluster, see Manually upgrade a cluster.
Network plug-in
Flannel.
Configure SNAT for VPC
Enable this feature to allow cluster access to the internet.
This feature can also be enabled for an existing cluster. For more information, see Enable internet access for a cluster.
RRSA OIDC
Enable this feature. RAM Roles for Service Accounts (RRSA) provides pod-level isolation for OpenAPI permissions, enabling fine-grained control over cloud resource access and reducing security risks.
You can also enable this feature for an existing cluster. For more information, see Isolate pod permissions by using RAM Roles for Service Accounts (RRSA).
After you enable this feature, see Obtain the URL and Alibaba Cloud Resource Name (ARN) of the OIDC provider. This ARN is required for authentication.
Step 1: Configure RRSA
CAA needs to operate ECS and Virtual Private Cloud (VPC) resources to create and manage confidential virtual machines. By configuring a Resource Access Management (RAM) role and a permission policy for the Cloud API Adaptor ServiceAccount through RRSA, scope these permissions down to the pod level.
1. Create a RAM role
Refer to Create a RAM role for a trusted identity provider to create a RAM role. In this example, the RAM role is named ack-caa-demo, and the key parameters are as follows:
Parameter | Description |
Identity provider type | OIDC. |
Identity provider | Select ack-rrsa-<CLUSTER_ID>, where <CLUSTER_ID> is your cluster ID. |
Condition |
|
Role name | ack-caa-demo. |
After you create the role, go to its details page. In the Basic Information section, find and record its ARN. This ARN is required for authentication.
2. Create a RAM policy
See the script below to create a RAM policy named
ack-caa-policythat grants permissions for ECS and VPC operations. For the procedure, see Create a custom permission policy.{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "ecs:RunInstances", "ecs:DeleteInstance", "ecs:DescribeInstanceAttribute", "ecs:CreateNetworkInterface", "ecs:DeleteNetworkInterface", "ecs:AttachNetworkInterface", "ecs:ModifyNetworkInterfaceAttribute", "ecs:DescribeNetworkInterfaceAttribute" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "vpc:DescribeVSwitchAttributes", "vpc:AllocateEipAddress", "vpc:ReleaseEipAddress", "vpc:AssociateEipAddress", "vpc:UnassociateEipAddress", "vpc:DescribeEipAddresses" ], "Resource": "*" } ] }Grant the permission policy
ack-caa-policyto the previously created RAM role. For instructions, see Manage permissions for a RAM role.
Step 2: Create a node pool and configure the security group
Create a node pool to deploy the controller workloads for the CAA solution. Also configure security group rules for the node pool to open the specific ports that CAA requires.
This node pool runs only the CAA control plane components and does not host workload pods. It does not require confidential computing instance types; regular nodes are sufficient.
-
Log on to the ACK console. In the left navigation pane, click Clusters.
-
On the Clusters page, click the name of your cluster. In the left navigation pane, click .
Click Create Node Pool and configure the parameters as prompted.
The following table describes only the key parameters. For more information, see Create and manage a node pool.
Parameter
Description
Managed node pool
Select Disable.
vSwitch
Select a vSwitch in a supported zone. The node pool adds nodes in this zone.
Operating system
Ubuntu 24.04 64-bit.
Expected Nodes
The initial number of nodes in the node pool. Set this to 1 or more.
The following are advanced configurations. Scroll down and expand Advanced Options (Optional).
Node Labels
Add the following node label to facilitate scheduling of the CAA controller.
Key:
node.kubernetes.io/workerValue: Leave this field empty.
In the node pool list, click the node pool name, and then click the Overview tab. In the Node Pool Information area, click the security group ID to go to the security group details page.
On the Inbound tab, click Add Rule and add the following two rules.
Protocol
Source
Destination
Description
Custom TCP
The CIDR block of the current VPC
15150
Allows secure communication between CAA components and confidential virtual machines.
Custom UDP
The CIDR block of the current VPC
4789
Enables network management for confidential containers based on VXLAN.
Step 3: Deploy CAA using a Helm chart
Deploy the following core components of CAA:
Cert Manager: A prerequisite for CAA deployment. It handles certificate validation for components such as the CAA webhook.
CAA (Cloud API Adaptor): Includes components such as the Kata Remote Runtime and the CAA node DaemonSet. Based on pod scheduling requests, they dynamically create confidential virtual machines to serve as runtime nodes for pods.
1. Deploy Cert Manager
Run the command that corresponds to the region where your cluster is deployed.
Chinese mainland
Install Cert Manager from the Alibaba Cloud image source to avoid timeouts when you pull community images.
mkdir cert-manager
cat << EOF > cert-manager/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- https://github.com/jetstack/cert-manager/releases/download/v1.15.3/cert-manager.yaml
images:
- name: quay.io/jetstack/cert-manager-controller
newName: registry-cn-hangzhou.ack.aliyuncs.com/dev/cert-manager-controller
- name: quay.io/jetstack/cert-manager-webhook
newName: registry-cn-hangzhou.ack.aliyuncs.com/dev/cert-manager-webhook
- name: quay.io/jetstack/cert-manager-cainjector
newName: registry-cn-hangzhou.ack.aliyuncs.com/dev/cert-manager-cainjector
EOF
kubectl apply -k cert-managerChina (Hong Kong) and overseas
Install Cert Manager directly from the community image.
mkdir cert-manager
cat << EOF > cert-manager/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- https://github.com/jetstack/cert-manager/releases/download/v1.15.3/cert-manager.yaml
EOF
kubectl apply -k cert-manager2. Deploy Cloud API Adaptor
Create a Helm-managed namespace.
kubectl apply -f - << EOF apiVersion: v1 kind: Namespace metadata: name: confidential-containers-system labels: app.kubernetes.io/managed-by: Helm annotations: meta.helm.sh/release-name: peerpods meta.helm.sh/release-namespace: confidential-containers-system EOFDownload the project source code.
git clone https://github.com/confidential-containers/cloud-api-adaptor.git -b v0.22.0 cd cloud-api-adaptor/src/cloud-api-adaptor/install/charts/peerpodsModify the relevant configurations in the
providers/alibabacloud.yamlfile.Parameter
Description
providerConfigs.alibabacloud.SECURITY_GROUP_IDSThe ID of the security group for the virtual machine. Set this to the security group ID of the node pool that you created in Step 2.
providerConfigs.alibabacloud.VSWITCH_IDThe vSwitch ID of the virtual machine. Set this to the vSwitch selected for the node pool created in Step 2.
providerConfigs.alibabacloud.REGIONThe region where the cluster is located. For example,
cn-beijing.providerConfigs.alibabacloud.IMAGEIDThe boot image for the virtual machine. Set this parameter to the image ID of the region where your cluster is deployed. For more information, see the following table.
The following table lists the image ID for each supported region.
Region
Region ID
Image ID
China (Beijing)
cn-beijingm-2ze2vxvrxsbue3sf8b02China (Hangzhou)
cn-hangzhoum-bp146ws6x3iyuwjvbdw2China (Hong Kong)
cn-hongkongm-j6c3kfz2vhu6ze04wacbSingapore
ap-southeast-1m-t4ng1w8ipua3c0o57horCreate a cluster Secret. The CAA DaemonSet uses this secret to make Alibaba Cloud API calls to create TDX instances.
Replace
${ALIBABA_CLOUD_ROLE_ARN}with the RAM role ARN, and${ALIBABA_CLOUD_OIDC_PROVIDER_ARN}with the RRSA OIDC provider ARN.kubectl create secret generic my-provider-creds \ -n confidential-containers-system \ --from-literal=ALIBABA_CLOUD_ROLE_ARN=${ALIBABA_CLOUD_ROLE_ARN} \ --from-literal=ALIBABA_CLOUD_OIDC_PROVIDER_ARN=${ALIBABA_CLOUD_OIDC_PROVIDER_ARN} \ --from-literal=ALIBABA_CLOUD_OIDC_TOKEN_FILE=/var/run/secrets/ack.alibabacloud.com/rrsa-tokens/tokenDeploy the CAA workload.
Chinese mainland
Create a file named
./mirror-values.yamlwith the following content to use the Alibaba Cloud image source.image: name: registry-cn-hangzhou.ack.aliyuncs.com/dev/coco-cloud-api-adaptor tag: v0.22.0 resourceCtrl: image: repository: registry-cn-hangzhou.ack.aliyuncs.com/dev/peerpod-ctrl tag: v0.22.0 authProxy: image: registry-cn-hangzhou.ack.aliyuncs.com/dev/kube-rbac-proxy:v0.14.0 webhook: image: repository: registry-cn-hangzhou.ack.aliyuncs.com/dev/peer-pods-webhook tag: v0.22.0 authProxy: image: registry-cn-hangzhou.ack.aliyuncs.com/dev/kube-rbac-proxy:v0.14.0 kata-deploy: image: reference: confidential-ai-registry.cn-shanghai.cr.aliyuncs.com/product/kata-deploy tag: 4.0.0 kubectlImage: reference: registry-cn-hangzhou.ack.aliyuncs.com/dev/kata-containers-kubectl tag: latestRun the following command to deploy CAA.
helm dependency update helm install peerpods . \ -f providers/alibabacloud.yaml \ -f ./mirror-values.yaml \ --set secrets.mode=reference \ --set secrets.existingSecretName=my-provider-creds \ --set alibabacloud.rrsa.enable=true \ --dependency-update \ -n confidential-containers-systemChina (Hong Kong) and overseas
Run the following command to deploy CAA.
helm dependency update helm install peerpods . \ -f providers/alibabacloud.yaml \ --set secrets.mode=reference \ --set secrets.existingSecretName=my-provider-creds \ --set alibabacloud.rrsa.enable=true \ --dependency-update \ -n confidential-containers-systemWait about 3 minutes, and then check the deployment status.
kubectl -n confidential-containers-system get podExpected output:
NAME READY STATUS RESTARTS AGE cloud-api-adaptor-daemonset-pnmpz 1/1 Running 0 20m cloud-api-adaptor-daemonset-qhlqk 1/1 Running 0 20m cloud-api-adaptor-daemonset-zpkt5 1/1 Running 0 20m kata-deploy-89x8h 1/1 Running 0 20m kata-deploy-fcpb8 1/1 Running 0 20m kata-deploy-jfkjg 1/1 Running 0 20m peerpodctrl-controller-manager-bfdb466fb-xl8xc 2/2 Running 0 20mThe expected output includes the
kata-deploy-*,cloud-api-adaptor-daemonset-*, andpeerpodctrl-controller-manager-*components, all with a status ofRunning, indicating a successful deployment.
Step 4: Deploy a sample application
This example deploys a sample application that uses runtimeClassName: kata-remote as the confidential container runtime. When the Pod is scheduled, Kata Remote triggers CAA to dynamically create a TDX confidential virtual machine.
Before deleting the cluster, delete all workloads that use runtimeClassName: kata-remote to avoid residual confidential virtual machine resources created by CAA.
Save the following content as
pod-caa-demo.yaml. This file is used to deploy a pod that uses the confidential container runtime.apiVersion: v1 kind: Pod metadata: name: pod-caa-demo spec: runtimeClassName: kata-remote containers: - image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/alinux3:latest name: hello command: - sh - -c - 'echo hello && sleep infinity'Deploy the
pod-caa-demo.yamlfile.kubectl apply -f pod-caa-demo.yamlWait about 3 minutes, and then check whether the application is deployed.
kubectl get pod pod-caa-demoExpected output:
NAME READY STATUS RESTARTS AGE pod-caa-demo 1/1 Running 0 52sGo to the ECS console, click Instances in the left navigation bar, and view the TDX confidential virtual machines that start with
podvm-. This indicates that CAA has created the underlying compute resources.
FAQ
No cloud-api-adaptor-daemonset pod is not running after you run kubectl -n confidential-containers-system get pod
Possible cause
The worker nodes may be missing the required labels, preventing the pods from being scheduled correctly.
Solution
Check the node labels.
kubectl get nodes --show-labelsAdd the required label to the worker nodes.
for NODE_NAME in $(kubectl get nodes -o jsonpath='{.items[*].metadata.name}'); do kubectl label node $NODE_NAME node.kubernetes.io/worker= doneWait for one to two minutes, and then check the pod status again.
kubectl -n confidential-containers-system get pod
References
Kata Containers CI Dashboard: Alibaba Cloud PeerPods has joined the official nightly CI tests. The test results are available on the Cloud API Adaptor sub-tab of the Confidential Containers tab.
Contact us
To ask product questions or provide suggestions, join our DingTalk group (ID: 30521601).