Container Service for Kubernetes：使用遠程證明保障機密容器環境的可信性

情境一：容器啟動前的環境可信驗證

面向叢集管理員，確保Pod僅在真實可信的機密環境中啟動。整個流程由系統後台自動完成，無需人工幹預。

1. 發起部署：管理員通過叢集API Server建立工作負載Pod後，節點上的kubelet會通過CRI（Container Runtime Interface）介面請求containerd建立Pod沙箱。containerd會檢查Pod指定的runtimeClassName，最終調用名為 kata-runtime 的底層 Kata Remote 運行時程式。

2. 建立機密虛擬機器：Kata Remote響應請求，調用阿里雲OpenAPI啟動一個基於硬體加密隔離的輕量級ECS TDX機密虛擬機器執行個體，作為Kubernetes Pod。

3. 強制遠程證明：在拉取業務鏡像前，虛擬機器內的Attestation Agent自動產生包含硬體簽名的運行環境“證據”（Evidence），並發送給Trustee服務進行驗證。

4. 驗證通過，運行工作負載：僅當Trustee確認Evidence有效後，Guest內部的管控邏輯才繼續執行後續操作，包括拉取鏡像和啟動容器。

情境二：容器運行時的遠程證明能力

面向運行中的容器化應用，允許其主動向外部服務證明自身所處環境的安全性，構建跨系統的信任鏈結。

1. 應用擷取Evidence：容器內應用通過訪問本地API介面（http://127.0.0.1:8006/aa/evidence）請求即時產生的遠程證明報告。

2. 驗證工作負載：應用將此Evidence發送給外部的Container服務使用者。

3. 外部驗證：服務使用者將Evidence送至其信任的Trustee服務進行驗證。驗證成功表明通訊對方確實運行於受保護的機密環境，實現動態信任建立。

1. 配置Trustee

在Trustee伺服器上完成策略配置，定義哪些環境特徵被視為可信。

1. 配置容器安全啟動策略。

   此策略檔案作為機密資源，在TDX Pod啟動過程中被讀取，觸發遠程證明流程。

   # 建立策略儲存目錄
   mkdir -p /opt/trustee/kbs/repository/default/container-policy
   
   # 寫入一個允許所有鏡像的策略檔案（僅供樣本）
   cat << EOF > /opt/trustee/kbs/repository/default/container-policy/insecure-accept-all
   {
       "default": [{"type": "insecureAcceptAnything"}],
       "transports": {}
   }
   EOF

2. 配置遠程證明策略。

   該策略定義了可信硬體與軟體環境的具體標準，例如要求運行在Intel TDX平台上。

   # 修改策略檔案 /opt/trustee/attestation-service/policies/opa/default.rego
   # 替換為適用於ECS TDX PeerPod的遠程證明策略
   cat << EOF > /opt/trustee/attestation-service/policies/opa/default.rego
   package policy
   
   import rego.v1
   
   default executables := 32
   default hardware := 97
   default configuration := 32
   default file_system := 32
   
   ##### ECS TDX PeerPod
   executables := 3 if {
   	input.tdx
   }
   
   hardware := 2 if {
   	# 驗證證據是否為Intel TDX類型
   	input.tdx.quote.header.tee_type == "81000000"
   	# 驗證廠商ID
   	input.tdx.quote.header.vendor_id == "939a7233f79c4ca9940a0db3957f0607"
   }
   
   configuration := 2 if {
   	input.tdx
   }
   
   file_system := 2 if {
   	input.tdx
   }
   EOF

3. 重啟Trustee服務使策略生效。

   service as restart

2. 部署啟用遠程證明的Pod

1. 準備Initdata並部署Pod。

   Initdata用於向PeerPod傳遞配置資訊，包括Trustee服務地址。

   # 替換為真實Trustee IP
   TRUSTEE_SERVICE_ENDPOINT=1.2.3.4
   
   # 產生initdata.toml檔案
   cat <<EOF > initdata.toml
   version = "0.1.0"
   algorithm = "sha256"
   [data]
   "aa.toml" = '''
   [eventlog_config]
   enable_eventlog = true
   [token_configs]
   [token_configs.kbs]
   url = "http://${TRUSTEE_SERVICE_ENDPOINT}:8080"
   '''
   "cdh.toml" = '''
   [kbc]
   name = "cc_kbc"
   url = "http://${TRUSTEE_SERVICE_ENDPOINT}:8080"
   [image]
   image_security_policy_uri = "kbs:///default/container-policy/insecure-accept-all"
   '''
   EOF
   
   # 對initdata進行gzip壓縮和 Base 64 編碼
   initdata=$(cat initdata.toml | gzip | base64 -w0)

   可通過echo $initdata查看initdata內容。

2. 建立Pod YAML檔案。

   將上一步產生的initdata字串寫入Pod中繼資料的annotations欄位中。

   # 建立一個名為 pod.yaml 的檔案
   cat << EOF > pod.yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-caa-demo
     annotations:
       io.katacontainers.config.hypervisor.cc_init_data: ${initdata}
   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"]
   EOF

3. 部署Pod。

   kubectl apply -f pod.yaml

   部署後，可執行kubectl get po pod-caa-demo查看Pod運行狀態。

4. 在Trustee伺服器上驗證遠程證明狀態。

   查看遠程證明服務的日誌，確認環境驗證是否成功。

   journalctl -u as -f 

   如果日誌中出現 Tdx Verifier/endorsement check passed，表示遠程證明成功，Pod已在可信環境中啟動。

1. 在容器內擷取遠程證明證據

curl 127.0.0.1:8006/aa/evidence?runtime_data=AAAA

2. 準備驗證環境

驗證過程依賴一個獨立且可信的Trustee執行個體。

1. （可選）執行yum install trustee -y在伺服器上安裝Trustee。

2. 配置用戶端驗證策略。

   在驗證節點的Trustee服務中建立新的策略檔案 /opt/trustee/attestation-service/policies/opa/client.rego。

   # 建立 client.rego 檔案，並寫入所有內容
   cat <<EOF > /opt/trustee/attestation-service/policies/opa/client.rego
   
   # 驗證從機密容器（TEE）擷取的Evidence
   package policy
   import rego.v1
   
   # --- 預設評分 ---
   default executables := 32
   default hardware := 97
   default configuration := 32
   default file_system := 32
   
   # --- 針對阿里雲 ECS TDX PeerPod 的驗證規則 ---
   # 例如：2代表“可信”(trustworthy)，3代表“認可”(affirming)
   # 如果輸入（input）的證據中包含 "tdx" 欄位，則認為其軟體棧是“認可”的
   executables := 3 if {
       input.tdx
   }
   
   # 硬體評分規則：如果同時滿足以下兩個條件，則硬體環境被評定為“可信”(trustworthy, 評分為2)。
   hardware := 2 if {
       # 檢查TEE類型欄位，必須是Intel TDX的標識符 "81000000"
       input.tdx.quote.header.tee_type == "81000000"
   
       # 檢查廠商ID欄位，必須是Intel的官方UUID
       input.tdx.quote.header.vendor_id == "939a7233f79c4ca9940a0db3957f0607"
   }
   
   # 如果輸入的是一個TDX證據，則認為其配置是“可信”的。
   configuration := 2 if {
       input.tdx
   }
   
   # 如果輸入的是一個TDX證據，則認為其檔案系統是“可信”的。
   file_system := 2 if {
       input.tdx
   }
   EOF

3. 重啟Trustee，使 client.rego 策略生效。

   service as-restful restart

3. 準備並發送驗證請求

將容器內擷取的Evidence提交至驗證服務進行校正。

1. 安全儲存證據原文（推薦做法）。

   為避免複製時因特殊字元導致錯誤，建議將Evidence存入檔案。

   # 建立名為 evidence.json 的臨時檔案
   cat > evidence.json

   執行後，粘貼完整的JSON字串，儲存並退出編輯模式。

2. 從檔案讀取證據並準備請求。

   # 從檔案讀取內容到變數
   EVIDENCE=$(cat evidence.json)
   
   # 將證據進行 Base 64 編碼並適配URL安全格式
   BASE64EVIDENCE=$(echo ${EVIDENCE} | base64 -w 0 2>/dev/null | tr '+/' '-_' | tr -d '=' )
   
   # 建立包含編碼後證據的請求體檔案
   cat << EOF > request.json
   {
       "verification_requests": [
           {
               "tee": "tdx",
               "evidence": "${BASE64EVIDENCE}"
           }
       ],
       "policy_ids": ["client"]
   }
   EOF

3. 發送驗證請求
   向本地驗證服務（預設連接埠 50005）的 /attestation 介面發送 POST 請求。
   

   curl -k -X POST http://127.0.0.1:50005/attestation \     -i \     -H 'Content-Type: application/json' \     -d @request.json

   執行後，響應體會包含 token 欄位（JWT 字串），即驗證令牌，請複製。

4. 解析並評估驗證結果

通過遠程證明Token，解析並擷取當前環境各子狀態的評分值。

1. 儲存驗證令牌。

   # 將 '<...>' 替換為實際擷取的 JWT 字串（不帶有雙引號本身）
   TOKEN='<在此處粘貼此前的JWT Token>'

2. 解析並查看評分

   echo $TOKEN | cut -d'.' -f2 | base64 -d |  jq '.submods.cpu0."ear.trustworthiness-vector"'

   預期輸出：

   base64: invalid input
   {
     "configuration": 2,
     "executables": 3,
     "file-system": 2,
     "hardware": 2
   }

   • base64: invalid input：可忽略此提示資訊。

   • {...}：JSON內容為驗證結果。各項評分與策略檔案設定一致，表明容器運行在符合要求的可信TDX環境中，驗證通過。