全部產品
Search
文件中心

Container Service for Kubernetes:在ACK叢集中基於機密虛擬機器實現CAA機密容器方案

更新時間:Jan 05, 2026

在金融風控、醫學健康等需要實現機密計算的情境下,您可以在ACK叢集中通過CAA(Cloud API Adaptor)方案部署機密計算工作負載,基於Intel® TDX技術保護敏感性資料免受外部攻擊或雲廠商的潛在威脅,以滿足行業的合規要求。

Intel® TDX是一項基於CPU硬體的ECS保護技術,詳情請參見TDX介紹

功能介紹

CAA( Cloud API Adaptor,也稱 Peer Pods)是雲原生CNCF機密容器Confidential Containers專案的核心組件之一,可通過調用雲平台 OpenAPI 將機密計算能力無縫整合到 Kubernetes 叢集中,自動建立機密虛擬機器。這些虛擬機器可作為特殊的“機密沙箱”來運行工作負載 Pod,使用底層硬體的 TEE 技術來保護工作負載的運行時資料安全。優勢如下。

  • 簡單易用:無需營運底層裸金屬架構或嵌套虛擬化技術棧,串連ACK叢集後可通過kubectl命令部署機密計算工作負載。

  • 安全機密:工作負載運行在ECS機密虛擬機器中,基於硬體級記憶體加密與隔離機制確保運行時資料的完整性與機密性。

  • 開源相容:ACK協同Confidential Containers社區實現了在叢集中基於 CAA 方案部署機密計算工作負載,通過代碼開源透明化(Code Transparency)接受社區持續審計。

您可以在ACK叢集中部署 CAA DaemonSet,然後在此基礎上部署機密計算工作負載。工作負載會以Pod的形式建立並運行在機密虛擬機器內,從而保證整個容器生命週期的運行時資料安全,防止虛擬機器之外的攻擊者攻擊。流程如下。

image

準備工作

步驟一:配置RRSA

為了讓CAA在機密容器情境下能夠管理和配置機密虛擬機器,您需要配置必要的身份(RAM 角色)和許可權(RAM 策略)。下文介紹如何讓Cloud API Adaptor ServiceAccount獲得操作ECS和VPC資源的許可權,實現Pod層級的精細許可權控制。

1、建立RAM角色

請參見建立可信實體為身份供應商的RAM角色建立一個RAM角色。本樣本RAM角色名稱為ack-caa-demo,主要參數如下。

配置項

描述

身份提供者類型

OIDC。

身份提供者

選擇ack-rrsa-<CLUSTER_ID>。其中,<CLUSTER_ID>為叢集ID。

條件

  • oidc:iss:保持預設。

  • oidc:aud:保持預設。

  • oidc:sub:手動添加該條件,進一步精確可扮演RAM角色的ServiceAccount(confidential-containers-system命名空間下的Cloud API Adaptor)。

    • 條件鍵:選擇oidc:sub

    • 運算子:選擇StringEquals

    • 條件值:按照頁面提示添加以下條件值:

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

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

角色名稱

ack-caa-demo。

建立後,您可以在RAM角色詳情頁面的基本資料地區,擷取其ARN,供後續配置身份認證使用。

2、建立權限原則

  1. 參見下方指令碼建立一個名為 ack-caa-policy的 RAM 權限原則,授予ECS和VPC的操作許可權。操作入口,請參見建立自訂權限原則

    {
      "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. 為此前建立的RAM角色授予權限原則ack-caa-policy。操作入口,請參見管理RAM角色的許可權

步驟二:建立節點池並配置安全性群組

您需要建立一個節點池,用於部署 CAA 方案的控制器工作負載。同時,您還需配置節點池的安全性群組規則,開放 CAA 方案依賴的特定連接埠。

  1. 登入Container Service管理主控台,在左側導覽列選擇叢集列表

  2. 叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,選擇節點管理 > 節點池

  3. 單擊建立節點池,按照頁面提示完成節點池的配置。

    下表僅介紹主要配置項。詳細配置項說明請參見建立和管理節點池

    配置項

    描述

    託管配置

    選擇不開啟

    交換器

    選擇可用性區域下的vSwitch,節點池會在該可用性區域下彈出節點。

    作業系統

    Ubuntu 22.04 64位

    期望節點數

    節點池初始節點數量,需為1個節點及以上。

    以下為進階配置(頁面下拉,展開進階選項(選填)

    節點標籤(Labels)

    新增如下節點標籤,便於CAA控制器的調度。

    • 鍵:node.kubernetes.io/worker

    • 值:留空

  4. 在節點池列表,單擊節點池名稱,然後單擊基本資料頁簽,在節點池資訊地區單擊安全性群組ID,跳轉至安全性群組詳情頁面。

  5. 入方向地區,單擊增加規則,增加如下兩條規則。

    協議

    訪問來源

    訪問目的

    說明

    自訂TCP

    本VPC網段

    15150

    支援CAA組件與機密虛擬機器之間的安全通訊。

    自訂UDP

    本VPC網段

    4789

    基於VXLAN實現機密容器的網路管理。

步驟三:部署 CAA

請參見下文部署CAA的兩個核心組件:

  • CoCo(Confidential Containers) Operator:負責自動化部署和管理機密容器所需的運行時環境,例如Kata Containers的遠程運行時Kata Remote Runtime。

  • CAA(Cloud API Adaptor) DaemonSet:CAA以DaemonSet的形式部署在節點上,可根據Pod調度請求動態建立機密虛擬機器作為Pod的運行時節點。

1、安裝CoCo Operator

參見以下命令進行安裝。

展開查看安裝命令

mkdir -p kustomize && cd kustomize
mkdir release && mkdir -p ccruntime/peer-pods

cat <<EOF > release/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- "github.com/confidential-containers/operator/config/release?ref=v0.17.0"

images:
- name: quay.io/confidential-containers/operator
  newName: registry-cn-hangzhou.ack.aliyuncs.com/dev/coco-operator
EOF

cat <<EOF > ccruntime/peer-pods/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- "github.com/confidential-containers/operator/config/samples/ccruntime/peer-pods?ref=v0.17.0"

images:
- name: quay.io/confidential-containers/reqs-payload
  newName: registry-cn-hangzhou.ack.aliyuncs.com/dev/coco-reqs-payload
- name: quay.io/kata-containers/kata-deploy-ci
  newName: registry-cn-hangzhou.ack.aliyuncs.com/dev/coco-kata-deploy-ci
- name: quay.io/kata-containers/kata-deploy
  newName: registry-cn-hangzhou.ack.aliyuncs.com/dev/coco-kata-deploy
EOF

kubectl apply -k release
kubectl apply -k ccruntime/peer-pods

2、部署 CAA DaemonSet

  1. 下載專案源碼。

    git clone https://github.com/confidential-containers/cloud-api-adaptor.git -b v0.17.0
    cd cloud-api-adaptor
  2. 修改 src/cloud-api-adaptor/install/overlays/alibabacloud/kustomization.yaml 檔案中的相關配置。

    參數

    說明

    newTag

    CAA Daemonset鏡像版本。修改為v0.17.0-alibaba-alpha0

    SECURITY_GROUP_IDS

    虛擬機器安全性群組ID,即步驟二所建立的節點池的安全性群組ID。

    VSWITCH_ID

    虛擬機器交換器ID,即步驟二所建立的節點池在可用性區域下的交換器ID。

    IMAGEID

    虛擬機器啟動鏡像。

    • 華北2(北京):修改為m-2zef6zaa0j0qz3sunhjp

    • 新加坡:修改為m-t4n9ocuen5sy6rhbxbk1

  3. 建立檔案 src/cloud-api-adaptor/install/overlays/alibabacloud/alibabacloud-cred.env,配置身份認證。內容如下。

    替換<role_arn>為RAM 角色ARN,<provider_arn>為RRSA OIDC的供應商 ARN。

    ALIBABA_CLOUD_ROLE_ARN=<role_arn>
    ALIBABA_CLOUD_OIDC_PROVIDER_ARN=<provider_arn>
    ALIBABA_CLOUD_OIDC_TOKEN_FILE=/var/run/secrets/ack.alibabacloud.com/rrsa-tokens/token
  4. 部署CAA工作負載。

    kubectl apply -k src/cloud-api-adaptor/install/overlays/alibabacloud

    等待大概3分鐘後,檢查部署狀態。

    kubectl -n confidential-containers-system get pod 

    預期輸出:

    NAME                                              READY   STATUS    RESTARTS   AGE
    cc-operator-controller-manager-5d79465b47-d8s2k   1/1     Running   0          2m11s
    cc-operator-daemon-install-trlvt                  1/1     Running   0          108s
    cc-operator-pre-install-daemon-qpvzw              1/1     Running   0          117s
    cloud-api-adaptor-daemonset-46spp                 1/1     Running   0          92s

    預期輸出包含 cc-operator-* 和 cloud-api-adaptor-daemonset-*組件,狀態均為 Running,表明部署成功。 

3、部署 peerpod-ctl 服務

在 CAA 營運過程中,可能會出現 Pod 已刪除但底層 ECS 虛擬機器(即 TDX 執行個體)殘留的情況,導致資源浪費。部署 peerpod-ctl可實現殘留虛擬機器的自動監測與動態回收。

常見情境如下:

  • 已部署應用 Pod,但cloud-api-adaptor-daemonset Pod被刪除、重啟或更新。系統檢測到原 Pod 串連失敗並建立新 Pod,但原 Pod 對應的虛擬機器可能會遺留。

  • 從 Kubernetes 側刪除了一個剛建立不久的 Pod,而該 Pod 對應的 TDX 執行個體仍在初始化中。

  1. 建立工作目錄。

    mkdir -p deployment/kustomize/peerpod-ctrl
  2. 建立 kustomization.yaml

    該檔案定義了資源來源及鏡像重新導向。

    cat << EOF > deployment/kustomize/peerpod-ctrl/kustomization.yaml
    apiVersion: kustomize.config.k8s.io/v1beta1
    kind: Kustomization
    resources:
    - "github.com/confidential-containers/cloud-api-adaptor/src/peerpod-ctrl/config/default?ref=v0.17.0"    
    
    images:
    - name: gcr.io/kubebuilder/kube-rbac-proxy
      newName: registry-cn-hangzhou.ack.aliyuncs.com/dev/kube-rbac-proxy
      newTag: v0.13.0
    - name: quay.io/confidential-containers/peerpod-ctrl
      newName: registry-cn-hangzhou.ack.aliyuncs.com/dev/peerpod-ctrl
      newTag: v0.17.0
    
    patchesStrategicMerge:
      - patch.yaml
    EOF
  3. 建立 patch.yaml

    該檔案通過 RRSA 機製為控制器注入 OIDC Token,使其具備操作阿里雲資源的身份。

    cat << EOF > deployment/kustomize/peerpod-ctrl/patch.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: peerpod-ctrl-controller-manager
      namespace: confidential-containers-system
    spec:
      template:
        spec:
          containers:
          - name: manager
            volumeMounts:
            - mountPath: /var/run/secrets/ack.alibabacloud.com/rrsa-tokens
              name: rrsa-oidc-token
              readOnly: true
          volumes:
          - name: rrsa-oidc-token
            projected:
              defaultMode: 420
              sources:
              - serviceAccountToken:
                  audience: sts.aliyuncs.com
                  expirationSeconds: 3600
                  path: token
    EOF
  4. 應用上述配置。

    kubectl apply -k deployment/kustomize/peerpod-ctrl
  5. 檢查服務是否正常啟動,確認Pod為Running狀態。

    kubectl -n confidential-containers-system get pod -l control-plane=controller-manager

步驟四:部署樣本應用

下文將部署一個樣本應用,使用 runtimeClassName: kata-remote 為機密容器運行時。當Pod調度時,Kata Remote將觸發CAA動態建立一台TDX機密虛擬機器。

重要

後續如需刪除叢集,刪除叢集前,請先刪除所有使用runtimeClassName: kata-remote的工作負載,以避免CAA建立的機密虛擬機器資源殘留。

  1. 將以下檔案儲存為pod-caa-demo.yaml,用於部署一個使用機密容器運行時的Pod。

    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. 部署pod-caa-demo.yaml。

    kubectl apply -f pod-caa-demo.yaml

    等待大概3分鐘,確認應用是否部署成功。

    kubectl get pod pod-caa-demo

    預期輸出:

    NAME           READY   STATUS    RESTARTS   AGE
    pod-caa-demo   1/1     Running   0          52s
  3. 訪問ECS管理主控台,在左側導覽列單擊執行個體,查看以podvm-開頭的TDX 機密虛擬機器,表明CAA已成功建立底層計算資源。

常見問題

執行kubectl -n confidential-containers-system get pod後僅有一個cc-operator-controller-manager服務運行

可能原因

Worker節點可能缺少必要標籤,導致相關Pod無法正確調度到節點。

解決方案
  1. 檢查節點標籤。

    kubectl get nodes --show-labels
  2. 為目標節點添加標籤。

    for NODE_NAME in $(kubectl get nodes -o jsonpath='{.items[*].metadata.name}'); do
      kubectl label node $NODE_NAME node.kubernetes.io/worker=
    done
  3. 等待1-2分鐘後,重新檢查Pod狀態。

    kubectl -n confidential-containers-system get pod

相關連結

聯絡我們

如有任何產品問題或使用建議,歡迎您加入釘群(釘群號:30521601)聯絡我們。