使用远程证明保障机密容器环境的可信性

场景一：容器启动前的环境可信验证

面向集群管理员，确保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压缩和 Base64 编码
   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)
   
   # 将证据进行 Base64 编码并适配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环境中，验证通过。