Deploy confidential containers with CAA

Updated at:

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 kubectl commands.

  • 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.

image

Prerequisites

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

  • oidc:iss: Keep the default value.

  • oidc:aud: Keep the default value.

  • oidc:sub: Manually add this condition to specify the ServiceAccounts that can assume this RAM role. These are the Cloud API Adaptor ServiceAccounts in the confidential-containers-system namespace.

    • Key: Select oidc:sub.

    • Operator: Select StringEquals.

    • Value: Add the following values as instructed on the page:

      • system:serviceaccount:confidential-containers-system:cloud-api-adaptor

      • system:serviceaccount:confidential-containers-system:peerpod-ctrl-controller-manager

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

  1. See the script below to create a RAM policy named ack-caa-policy that 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": "*"
        }
      ]
    }
  2. Grant the permission policy ack-caa-policy to 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.
  1. Log on to the ACK console. In the left navigation pane, click Clusters.

  2. On the Clusters page, click the name of your cluster. In the left navigation pane, click Nodes > Node Pools.

  3. 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/worker

    • Value: Leave this field empty.

  4. 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.

  5. 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-manager

China (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-manager

2. Deploy Cloud API Adaptor

  1. 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
    EOF
  2. Download 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/peerpods
  3. Modify the relevant configurations in the providers/alibabacloud.yaml file.

    Parameter

    Description

    providerConfigs.alibabacloud.SECURITY_GROUP_IDS

    The 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_ID

    The vSwitch ID of the virtual machine. Set this to the vSwitch selected for the node pool created in Step 2.

    providerConfigs.alibabacloud.REGION

    The region where the cluster is located. For example, cn-beijing.

    providerConfigs.alibabacloud.IMAGEID

    The 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-beijing

    m-2ze2vxvrxsbue3sf8b02

    China (Hangzhou)

    cn-hangzhou

    m-bp146ws6x3iyuwjvbdw2

    China (Hong Kong)

    cn-hongkong

    m-j6c3kfz2vhu6ze04wacb

    Singapore

    ap-southeast-1

    m-t4ng1w8ipua3c0o57hor

  4. Create 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/token
  5. Deploy the CAA workload.

    Chinese mainland

    Create a file named ./mirror-values.yaml with 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: latest

    Run 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-system

    China (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-system

    Wait about 3 minutes, and then check the deployment status.

    kubectl -n confidential-containers-system get pod 

    Expected 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          20m

    The expected output includes the kata-deploy-*cloud-api-adaptor-daemonset-*, and peerpodctrl-controller-manager-* components, all with a status of Running, 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.

Important

Before deleting the cluster, delete all workloads that use runtimeClassName: kata-remote to avoid residual confidential virtual machine resources created by CAA.

  1. 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'
  2. Deploy the pod-caa-demo.yaml file.

    kubectl apply -f pod-caa-demo.yaml

    Wait about 3 minutes, and then check whether the application is deployed.

    kubectl get pod pod-caa-demo

    Expected output:

    NAME           READY   STATUS    RESTARTS   AGE
    pod-caa-demo   1/1     Running   0          52s
  3. Go 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

  1. Check the node labels.

    kubectl get nodes --show-labels
  2. Add 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=
    done
  3. Wait for one to two minutes, and then check the pod status again.

    kubectl -n confidential-containers-system get pod

References

Contact us

To ask product questions or provide suggestions, join our DingTalk group (ID: 30521601).