文档

• 1: 概览
• 2: 快速开始
• 2.1: 前提条件
• 2.2: 安装
• 2.3: 示例工作负载
• 2.4: 加固工作负载
• 3: 术语对照表
• 4: 云提供商
• 4.1: AWS (EKS)
• 4.2: Azure Kubernetes Service (AKS)
• 4.3: Google Cloud Platform (GCP)
• 4.4: 阿里云
• 5: NVIDIA GPU 示例
• 6: NVIDIA 机密 NIM 部署
• 7: 使用 SNP 内存加密启动容器

1 - 概览

什么是 Confidential Containers（CoCo）项目？

Confidential Containers（CoCo）通过将 Pod 运行在机密虚拟机（Confidential Virtual Machine）中， 让云原生工作负载在几乎无需修改的情况下利用机密计算硬件提供的安全能力。

Confidential Containers 将机密计算保护能力扩展到复杂工作负载场景。 借助 Confidential Containers，敏感工作负载即便运行在不受信任的主机环境（untrusted hosts）上， 也能够抵御来自已遭入侵或恶意的用户、软件和管理员的攻击。

Confidential Containers 提供一个 工作负载部署、远程证明（Remote Attestation） 以及 密钥/机密信息（Keys/Secrets）分发 的端到端框架。

Confidential Containers 支持哪些硬件？

在裸金属环境下，Confidential Containers 支持以下平台：

硬件加速器（Accelerators）

NVIDIA 多设备透传要求将主机上的全部 GPU 分配给同一个 Pod。 NVIDIA Protected PCIe 还要求在 Pod 中列出 NVIDIA NVLink 交换机。

云平台

还可以借助cloud-api-adaptor在云环境中部署Confidential Containers。

目前支持以下平台。

远程证明（Attestation）

Confidential Containers 提供了一个名为 Trustee 的远程证明与密钥管理引擎，可为以下平台提供远程证明：

Trustee 既可以与 Confidential Containers 配合使用，也可以用于对独立运行的机密虚拟机（即非 CoCo 场景）进行远程证明。 更多信息请参见“远程证明（Attestation）”章节。

2 - 快速开始

本节将介绍部署 Confidential Containers 所需的软硬件前提条件、 如何使用 Helm Chart 完成安装、如何验证安装结果， 以及如何运行使用 Confidential Containers 的 Pod。

2.1 - 前提条件

本节将介绍使用 Helm Chart 安装 Confidential Containers 所需的软硬件前提条件。

2.2 - 安装

使用 Helm 安装 CoCo

通过 Confidential Containers Charts 仓库提供的 Helm Chart 安装 CoCo 运行时。

• 最新版本
• 指定版本

helm install coco oci://ghcr.io/confidential-containers/charts/confidential-containers \
  --namespace coco-system \
  --create-namespace

helm install coco oci://ghcr.io/confidential-containers/charts/confidential-containers \
  --version <VERSION> \
  --namespace coco-system \
  --create-namespace

helm install coco oci://ghcr.io/confidential-containers/charts/confidential-containers \
  --version 0.18.0 \
  --namespace coco-system \
  --create-namespace

等待所有 Pod 的 STATUS 变为 Running。

kubectl get pods -n coco-system --watch

如果需要了解特定场景的安装选项（例如 s390x、peer-pods）或高级配置，请参见 Charts 仓库文档。

验证安装

检查预期的 RuntimeClass 是否已创建。

kubectl get runtimeclass

可用的 RuntimeClass 取决于具体架构：

• x86_64
• s390x
• peer-pods

卸载

如需卸载 Confidential Containers 并删除 coco-system 命名空间，请执行：

helm uninstall coco --namespace coco-system
kubectl delete namespace coco-system

2.3 - 示例工作负载

创建示例 Confidential Containers 工作负载

使用 Helm Chart 安装 Confidential Containers 后，只需为 Pod 添加一个 RuntimeClass， 即可运行 CoCo 工作负载。 我们使用 kata-qemu-coco-dev RuntimeClass，它会在不依赖机密计算硬件支持的情况下运行 CoCo。 首先，使用一个未加密的容器镜像进行演示。

本示例使用如下 YAML 所示的 nginx 镜像：

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx
  name: nginx
  annotations:
    io.containerd.cri.runtime-handler: kata-qemu-coco-dev
spec:
  containers:
  - name: nginx
    image: nginx:1.29.4
  dnsPolicy: ClusterFirst
  runtimeClassName: kata-qemu-coco-dev

对于大多数基础的工作负载来说，通常只需在 Pod YAML 中设置 runtimeClassName 和 runtime-handler 注解即可。

按照上面的内容创建一个 Pod YAML 文件（本示例命名为 nginx.yaml）。

创建工作负载：

kubectl apply -f nginx.yaml

输出示例：

pod/nginx created

确认 Pod 已成功创建并处于运行状态：

kubectl get pods

输出示例：

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          3m50s

2.4 - 加固工作负载

现在你已经部署了一个简单的 Confidential Containers 工作负载， 接下来可以进一步了解如何将其加固到适用于生产环境的水平。 本页重点介绍你需要做出的几个关键决策：

1. 为你的硬件选择合适的 RuntimeClass
2. 理解并配置用于保护工作负载的各类策略
3. 利用额外的安全特性进一步提升防护能力

选择合适的 RuntimeClass

在前面的示例中，我们使用的是 kata-qemu-coco-dev， 它主要用于测试场景，不依赖机密计算硬件支持。 如果是在生产环境中部署，则必须选择与实际 TEE 硬件相匹配的 RuntimeClass。

RuntimeClass 选择指南

用于开发与测试：

• kata-qemu-coco-dev - 不依赖 TEE 硬件的测试运行时（⚠️ 不提供安全保证）

用于 x86_64 裸金属生产环境：

• kata-qemu-tdx - Intel TDX（Trust Domain Extensions）
• kata-qemu-snp - AMD SEV-SNP（Secure Encrypted Virtualization）
• kata-qemu-sev - AMD SEV（较早一代）
• kata-qemu-nvidia-gpu-tdx - NVIDIA GPU 加 Intel TDX 组合
• kata-qemu-nvidia-gpu-snp - NVIDIA GPU 加 AMD SNP 组合

用于 s390x 生产环境：

• kata-qemu-se - IBM Secure Execution

用于云上部署（Peer Pods）：

• kata-remote - 面向 AWS、Azure、GCP 等平台的 Cloud API Adaptor

示例：迁移到生产环境配置

下面展示如何将 Pod 更新为使用真实的 TEE 硬件。

以 Intel TDX 为例：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-production
spec:
  runtimeClassName: kata-qemu-tdx
  containers:
  - image: bitnami/nginx:latest
    name: nginx

使用Intel TDX 加 NVIDIA Hopper GPU：

apiVersion: v1
kind: Pod
metadata:
  name: cuda-vectoradd-kata
  namespace: default
spec:
  runtimeClassName: kata-qemu-nvidia-gpu-tdx
  restartPolicy: Never
  containers:
  - name: cuda-vectoradd
    image: "nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04"
    resources:
      limits:
        nvidia.com/pgpu: "1"
        memory: 16Gi

关于 Hopper、Blackwell 多 GPU 示例，以及 Hopper PPCIE 标签配置，请参见 NVIDIA GPU 示例。

理解 CoCo 策略体系

Confidential Containers 使用三类策略（policy），分别在不同层面保护工作负载。 若要加固生产环境部署，理解这三类策略至关重要。

三类策略

1. Kata Agent 策略（TEE 内）

Kata Agent 策略决定了 Kata Agent 在 TEE 内允许执行哪些操作。 这是防御恶意或已被入侵的 Kubernetes 控制平面的第一道防线。

典型用途包括：

• 禁止对生产 Pod 执行 kubectl exec
• 限制允许启动的容器镜像
• 控制允许执行的命令

下面是一个较为严格的 Kata Agent 策略示例：

package agent_policy
import rego.v1

default CreateContainerRequest := false
default ExecProcessRequest := false

# Only allow specific image digests
CreateContainerRequest if {
	input.storages[0].source == "docker.io/library/nginx@sha256:abc123..."
}

Kata Agent 策略会嵌入到 Init-Data 配置文件中。 该文件还可提供其他配置，例如 Trustee 的地址信息。

延伸阅读：Kata Agent 策略和 Init-Data

2. KBS 资源策略（KBS 侧）

KBS 资源策略用于控制在何种条件下释放哪些机密信息。 它会检查工作负载提交的证明令牌，并据此做出决策。

典型用途包括：

• 验证工作负载是否使用了特定的 Kata Agent 策略（通过 Init-Data 哈希）
• 仅向通过 TDX 远程证明的 TDVM 实例释放数据库凭据
• 要求特定的信任级别（例如 affirming 或 contraindicated）
• 为不同平台（TDX 或 SNP）下发不同的机密信息

示例：校验 Init-Data 哈希

当你在 Pod 中提供 Init-Data（其中包含 Kata Agent 策略）时， 证明服务（Attestation Service）会对其进行校验，并将相应哈希写入令牌。 你的 KBS 资源策略可以进一步验证这个特定的 Init-Data 哈希， 从而确保实际使用的是期望的 Kata Agent 策略与配置。

package policy
import rego.v1

default allow = false

# Only release secrets to workloads with the expected Init-Data hash
allow if {
	input["submods"]["cpu0"]["ear.status"] == "affirming"
	# Verify the specific Init-Data hash (includes kata agent policy + config)
	input["submods"]["cpu0"]["ear.veraison.annotated-evidence"]["init_data"] == "expected-hash-here"
}

请使用你在 initdata.toml 中指定的哈希算法计算期望值。 例如，对 TDX 场景，通常会使用 sha384，此时可在命令行中执行：

sha384sum initdata.toml

延伸阅读：KBS 资源策略

3. 远程证明策略（Attestation Service 侧）

远程证明策略定义了如何评估硬件证据，包括： 接受哪些测量值、与哪些参考值进行比对，以及如何计算信任向量。

典型用途包括：

• 定义可接受的固件版本
• 为不同工作负载指定所需的安全级别
• 将硬件测量值映射为可信声明（trust claims）

延伸阅读：Attestation Service Policies

额外的安全特性

完成基础配置后，可以进一步了解以下功能以增强整体安全性： 功能概览

生产环境快速检查清单

在部署到生产环境之前，请确认已完成以下事项：

• 已根据实际硬件选择正确的 RuntimeClass
• 已生成并嵌入适合当前工作负载的 Kata Agent 策略
• 已在 KBS 中配置 KBS 资源策略
• 已向证明服务预置参考值

后续步骤

• 部署 Trustee： 参见Trustee 安装，以启用远程证明
• 深入策略体系： 参见各类策略说明
• 云上部署： 参见AWS、Azure、GCP 云平台示例

3 - 术语对照表

本文根据当前 CoCo 英文文档整理出常见的专业名称、关键术语与专有名词，便于中文文档翻译时保持用词一致。

说明：

• 组件名、项目名、协议名、工具名以及 RuntimeClass 名称通常保留英文。
• 中文列给出建议译法；对于不宜直译的项目名，采用“保留英文 + 中文解释”的方式。
• 该表会随着英文文档演进持续补充和调整。

核心项目与组件

安全、TEE 与证明术语

Kubernetes 与容器术语

平台、硬件与云环境

标准、协议与工具

扩展项目名与场景术语

RuntimeClass 与字面标识符

以下名称通常不翻译，中文仅作解释。

4 - 云提供商

4.1 - AWS (EKS)

说明： 本文为英文文档的中文译版，英文原版请参见 AWS 示例（英文版）。

本文将介绍如何在 AWS Elastic Kubernetes Service (EKS) 上配置 CAA（即 Peer Pods），具体包括：

• 一个基于 Elastic Kubernetes Service (EKS) 的单工作节点 Kubernetes 集群
• 运行在该 Kubernetes 集群上的 CAA
• 一个由 CAA PodVM 支撑的 Nginx Pod

前提条件

安装所需工具：

• 安装 kubectl
• 安装 Helm
• 安装 aws CLI 工具
• 安装 eksctl CLI 工具
• 确保已安装 curl、git 和 jq

AWS 准备工作

• 为 AWS CLI 访问设置 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY（或 AWS_PROFILE）以及 AWS_REGION

说明： 除了静态凭证外，也可以在 EKS 上使用 IRSA（IAM Roles for Service Accounts）。使用 IRSA 时，CAA Pod 通过 OIDC 完成认证，无需在 Kubernetes Secret 中保存静态 AWS 密钥。集群初始化步骤中仍然需要 AWS_REGION 和临时凭证。

• 设置区域：

• AMD SEV-SNP
• 非机密计算

export AWS_REGION="us-east-2"

export AWS_REGION="us-east-2"

使用 EKS 部署 Kubernetes

按需修改以下环境变量：

export CLUSTER_NAME="caa-$(date '+%Y%m%b%d%H%M%S')"
export CLUSTER_NODE_TYPE="m5.xlarge"
export CLUSTER_NODE_FAMILY_TYPE="Ubuntu2204"
export SSH_KEY=~/.ssh/id_rsa.pub

以下示例使用默认的 AWS VPC-CNI 创建 EKS 集群：

eksctl create cluster --name "$CLUSTER_NAME" \
    --node-type "$CLUSTER_NODE_TYPE" \
    --node-ami-family "$CLUSTER_NODE_FAMILY_TYPE" \
    --nodes 1 \
    --nodes-min 0 \
    --nodes-max 2 \
    --node-private-networking \
    --kubeconfig "$CLUSTER_NAME"-kubeconfig

等待集群创建完成。

为集群节点添加 node.kubernetes.io/worker= 标签：

for NODE_NAME in $(kubectl get nodes -o jsonpath='{.items[*].metadata.name}'); do
  kubectl label node $NODE_NAME node.kubernetes.io/worker=
done

放通所需网络端口

EKS_VPC_ID=$(aws eks describe-cluster --name "$CLUSTER_NAME" \
--query "cluster.resourcesVpcConfig.vpcId" \
--output text)
echo $EKS_VPC_ID

EKS_CLUSTER_SG=$(aws eks describe-cluster --name "$CLUSTER_NAME" \
  --query "cluster.resourcesVpcConfig.clusterSecurityGroupId" \
  --output text)
echo $EKS_CLUSTER_SG

EKS_VPC_CIDR=$(aws ec2 describe-vpcs --vpc-ids "$EKS_VPC_ID" \
--query 'Vpcs[0].CidrBlock' --output text)
echo $EKS_VPC_CIDR

# agent-protocol-forwarder 端口
aws ec2 authorize-security-group-ingress --group-id "$EKS_CLUSTER_SG" --protocol tcp --port 15150 --cidr "$EKS_VPC_CIDR"

# vxlan 端口
aws ec2 authorize-security-group-ingress --group-id "$EKS_CLUSTER_SG" --protocol tcp --port 9000 --cidr "$EKS_VPC_CIDR"
aws ec2 authorize-security-group-ingress --group-id "$EKS_CLUSTER_SG" --protocol udp --port 9000 --cidr "$EKS_VPC_CIDR"

说明：

• 端口 15150 是 CAA 连接 PodVM 内 agent-protocol-forwarder 时使用的默认端口。
• 端口 9000 是 CAA 使用的 VXLAN 端口。请确保它与 Kubernetes CNI 使用的 VXLAN 端口不冲突。

配置认证

选择 CAA 与 AWS 交互时的认证方式。静态凭证方式通过 Kubernetes Secret 保存访问密钥；IRSA 则通过 OIDC 联邦让 Pod 直接承担 IAM 角色，无需静态密钥。

• 静态凭证
• IRSA (EKS)

OIDC_ID=$(aws eks describe-cluster \
  --name ${CLUSTER_NAME} \
  --region ${AWS_REGION} \
  --query "cluster.identity.oidc.issuer" \
  --output text | awk -F'/' '{print $NF}')

aws iam list-open-id-connect-providers | grep ${OIDC_ID}

eksctl utils associate-iam-oidc-provider \
  --cluster ${CLUSTER_NAME} \
  --region ${AWS_REGION} \
  --approve

export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

export OIDC_PROVIDER=$(aws eks describe-cluster \
  --name ${CLUSTER_NAME} \
  --region ${AWS_REGION} \
  --query "cluster.identity.oidc.issuer" \
  --output text | sed 's|https://||')

export NAMESPACE="confidential-containers-system"
export CAA_SERVICE_ACCOUNT="cloud-api-adaptor"
export CAA_ROLE_NAME="CAA-IRSA-Role"

cat > /tmp/caa-trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::${ACCOUNT_ID}:oidc-provider/${OIDC_PROVIDER}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "${OIDC_PROVIDER}:sub": "system:serviceaccount:${NAMESPACE}:${CAA_SERVICE_ACCOUNT}",
          "${OIDC_PROVIDER}:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}
EOF

aws iam create-role \
  --role-name ${CAA_ROLE_NAME} \
  --assume-role-policy-document file:///tmp/caa-trust-policy.json \
  --description "IRSA role for Cloud API Adaptor on EKS"

aws iam attach-role-policy \
  --role-name ${CAA_ROLE_NAME} \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess

export CAA_ROLE_ARN=$(aws iam get-role \
  --role-name ${CAA_ROLE_NAME} \
  --query 'Role.Arn' \
  --output text)

echo "CAA Role ARN: ${CAA_ROLE_ARN}"

export CTRL_SERVICE_ACCOUNT="peerpodctrl-controller-manager"
export CTRL_ROLE_NAME="PeerpodCtrl-IRSA-Role"

cat > /tmp/peerpod-ctrl-trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::${ACCOUNT_ID}:oidc-provider/${OIDC_PROVIDER}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "${OIDC_PROVIDER}:sub": "system:serviceaccount:${NAMESPACE}:${CTRL_SERVICE_ACCOUNT}",
          "${OIDC_PROVIDER}:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}
EOF

aws iam create-role \
  --role-name ${CTRL_ROLE_NAME} \
  --assume-role-policy-document file:///tmp/peerpod-ctrl-trust-policy.json \
  --description "IRSA role for PeerPod Controller on EKS"

aws iam attach-role-policy \
  --role-name ${CTRL_ROLE_NAME} \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess

export CTRL_ROLE_ARN=$(aws iam get-role \
  --role-name ${CTRL_ROLE_NAME} \
  --query 'Role.Arn' \
  --output text)

echo "Controller Role ARN: ${CTRL_ROLE_ARN}"

部署 CAA Helm Chart

下载 CAA Helm 部署资源

• 版本：
• 最新发布
• 最新构建
• DIY

CAA_VERSION="$(
  curl -fsSL \
    "https://api.github.com/repos/confidential-containers/cloud-api-adaptor/releases/latest" |
    jq -er '.tag_name | sub("^v"; "")'
)"
curl -LO "https://github.com/confidential-containers/cloud-api-adaptor/archive/refs/tags/v${CAA_VERSION}.tar.gz"
tar -xvzf "v${CAA_VERSION}.tar.gz"
cd "cloud-api-adaptor-${CAA_VERSION}/src/cloud-api-adaptor/install/charts/peerpods"

export CAA_BRANCH="main"
curl -LO "https://github.com/confidential-containers/cloud-api-adaptor/archive/refs/heads/${CAA_BRANCH}.tar.gz"
tar -xvzf "${CAA_BRANCH}.tar.gz"
cd "cloud-api-adaptor-${CAA_BRANCH}/src/cloud-api-adaptor/install/charts/peerpods"

导出 PodVM 镜像版本

导出 peer pods 所用的 PodVM 镜像 ID。该变量告诉部署工具在 AWS 中创建 peer pod 虚拟机时应使用哪个 PodVM 镜像版本。

镜像来自 CoCo 社区镜像库（或由你手动构建），并且必须与当前 CAA 发布版本匹配。

• 版本：
• 最新发布
• 最新构建
• DIY

export PODVM_AMI_ID=$(aws ec2 describe-images \
    --filters Name=name,Values="podvm-ubuntu-amd64-${CAA_VERSION//./-}" \
    --query 'Images[*].[ImageId]' --output text)

echo $PODVM_AMI_ID

导出 CAA 容器镜像路径

定义要部署的 Cloud API Adaptor（CAA）容器镜像。 这些变量指定了部署工具所要拉取和运行的 CAA 镜像及其架构专属 tag。 tag 与 CAA 发布版本对应，以确保与所选 PodVM 镜像和配置兼容。

• 版本：
• 最新发布
• 最新构建
• DIY

export CAA_IMAGE="quay.io/confidential-containers/cloud-api-adaptor"
export CAA_TAG="v${CAA_VERSION}-amd64"

export CAA_IMAGE="quay.io/confidential-containers/cloud-api-adaptor"

export CAA_TAG=""

选择 peer-pods 机型

• AMD SEV-SNP
• 非机密计算

export PODVM_INSTANCE_TYPE="m6a.large"
export DISABLECVM="false"

export PODVM_INSTANCE_TYPE="t3.large"
export DISABLECVM="true"

填充 providers/aws.yaml 文件

全部可用配置项可在以下两个位置找到：

• 主 chart values
• AWS 专属 values

运行以下命令更新 providers/aws.yaml 文件：

cat <<EOF > providers/aws.yaml
provider: aws
image:
  name: "${CAA_IMAGE}"
  tag: "${CAA_TAG}"
providerConfigs:
   aws:
      DISABLECVM: ${DISABLECVM}
      PODVM_AMI_ID: "${PODVM_AMI_ID}"
      PODVM_INSTANCE_TYPE: "${PODVM_INSTANCE_TYPE}"
      VXLAN_PORT: 9000
EOF

安装 cert-manager

CAA 依赖 cert-manager。除非环境中已经安装，否则请使用以下方式部署：

helm repo add jetstack https://charts.jetstack.io
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set crds.enabled=true \
  --wait \
  --timeout 5m

在 Kubernetes 集群中部署 Helm Chart

1. 创建由 Helm 管理的命名空间：

   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. 创建凭证并安装 Helm Chart：

   下面命令使用了 -f 和 --set 这两个自定义选项，其含义可参考这里。

• 静态凭证
• IRSA (EKS)

kubectl create secret generic my-provider-creds \
  -n confidential-containers-system \
  --from-literal=AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID} \
  --from-literal=AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY} \
  --from-file=id_rsa.pub=${SSH_KEY}

helm install peerpods . \
  -f providers/aws.yaml \
  --set secrets.mode=reference \
  --set secrets.existingSecretName=my-provider-creds \
  --dependency-update \
  -n confidential-containers-system

helm install peerpods . \
  -f providers/aws.yaml \
  --set "daemonset.serviceAccount.annotations.eks\.amazonaws\.com/role-arn=${CAA_ROLE_ARN}" \
  --set "resourceCtrl.serviceAccount.annotations.eks\.amazonaws\.com/role-arn=${CTRL_ROLE_ARN}" \
  --dependency-update \
  -n confidential-containers-system

kubectl get serviceaccount cloud-api-adaptor \
  -n confidential-containers-system \
  -o jsonpath='{.metadata.annotations.eks\.amazonaws\.com/role-arn}'

CAA_POD=$(kubectl get pods -n confidential-containers-system \
  -l app=cloud-api-adaptor \
  -o jsonpath='{.items[0].metadata.name}')

kubectl exec -n confidential-containers-system ${CAA_POD} -- env | grep AWS

通用的 Peer Pods Helm Chart 部署说明也可参考这里。

运行示例应用

确认 RuntimeClass 已创建

部署 CAA 后，请确认已创建 RuntimeClass：

kubectl get runtimeclass

当你看到名为 kata-remote 的 RuntimeClass 时，就说明部署成功。成功输出类似如下：

$ kubectl get runtimeclass
NAME          HANDLER       AGE
kata-remote   kata-remote   7m18s

部署工作负载

创建一个 nginx deployment：

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      runtimeClassName: kata-remote
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        imagePullPolicy: Always
EOF

确认 pod 已成功启动：

kubectl get pods -n default

你可以通过运行以下命令确认 peer pod VM 是否已经创建：

aws ec2 describe-instances --filters "Name=tag:Name,Values=podvm*" \
   --query 'Reservations[*].Instances[*].[InstanceId, Tags[?Key==`Name`].Value | [0]]' --output table

此时你应该能看到与 pod nginx 对应的虚拟机。

说明： 如果遇到问题，请查看故障排查指南。

清理

删除所有使用 kata-remote runtimeclass 运行的 Pod。可以使用以下命令：

kubectl get pods -A -o custom-columns='NAME:.metadata.name,NAMESPACE:.metadata.namespace,RUNTIMECLASS:.spec.runtimeClassName' | grep kata-remote | awk '{print $1, $2}'

确认所有 peer-pod VM 都已删除。你可以使用以下命令列出所有 peer-pod VM（名称前缀为 podvm）及其状态：

aws ec2 describe-instances --filters "Name=tag:Name,Values=podvm*" \
--query 'Reservations[*].Instances[*].[InstanceId, Tags[?Key==`Name`].Value | [0], State.Name]' --output table

运行以下命令删除 EKS 集群：

eksctl delete cluster --name=$CLUSTER_NAME

4.2 - Azure Kubernetes Service (AKS)

说明： 本文为英文文档的中文译版，英文原版请参见 Azure 示例（英文版）。

本文将介绍如何在 Azure Kubernetes Service (AKS) 上配置 CAA（即 Peer Pods），具体包括：

• 一个基于 Azure Kubernetes Service (AKS) 的单工作节点 Kubernetes 集群
• 运行在该 Kubernetes 集群上的 CAA
• 一个由 CAA PodVM 支撑的 Nginx Pod

Confidential Containers 也支持将 Azure Key Vault 用作 Trustee 的资源后端。 更多信息

前提条件

安装所需工具：

• 安装 kubectl
• 安装 Helm
• 安装 az CLI 工具
• 确保已安装 curl、git、jq 和 sipcalc

Azure 准备工作

登录 Azure

以下许多步骤均需先登录 Azure 账号：

az login

获取你的订阅 ID：

export AZURE_SUBSCRIPTION_ID=$(az account show --query id --output tsv)

设置区域：

• AMD SEV-SNP
• Intel TDX
• 非机密计算

export AZURE_REGION="eastus"

export AZURE_REGION="eastus2"

export AZURE_REGION="eastus"

资源组

说明： 如果你已经有可用的资源组，可以跳过这一步。请将资源组名称导出到环境变量 AZURE_RESOURCE_GROUP。

运行以下命令创建 Azure 资源组：

export AZURE_RESOURCE_GROUP="caa-rg-$(date '+%Y%m%b%d%H%M%S')"

az group create \
  --name "${AZURE_RESOURCE_GROUP}" \
  --location "${AZURE_REGION}"

使用 AKS 部署 Kubernetes

按需修改以下环境变量：

export CLUSTER_NAME="caa-$(date '+%Y%m%b%d%H%M%S')"
export AKS_WORKER_USER_NAME="azuser"
export AKS_RG="${AZURE_RESOURCE_GROUP}-aks"
export SSH_KEY=~/.ssh/id_rsa.pub

说明： 你也可以通过增加参数 --vnet-subnet-id $MY_SUBNET_ID，将工作节点部署到现有的 Azure Virtual Network (VNet) 和子网中。

将一个单工作节点的 AKS 集群部署到你刚刚创建的资源组中：

az aks create \
  --resource-group "${AZURE_RESOURCE_GROUP}" \
  --node-resource-group "${AKS_RG}" \
  --name "${CLUSTER_NAME}" \
  --enable-oidc-issuer \
  --enable-workload-identity \
  --location "${AZURE_REGION}" \
  --node-count 1 \
  --node-vm-size Standard_F4s_v2 \
  --nodepool-labels node.kubernetes.io/worker= \
  --ssh-access disabled \
  --admin-username "${AKS_WORKER_USER_NAME}" \
  --os-sku Ubuntu

将 kubeconfig 下载到本地，以便用 kubectl 访问集群：

az aks get-credentials \
  --resource-group "${AZURE_RESOURCE_GROUP}" \
  --name "${CLUSTER_NAME}"

用户分配身份与联合凭证

CAA 需要具备访问 Azure API 的权限。做法是将工作负载身份（workload identity）关联到 CAA 的服务账号上。该工作负载身份（即用户分配身份）将在下一步被授予创建虚拟机、获取镜像和访问网络的权限。

说明： 如果你使用的是现有 AKS 集群，可能需要先配置工作负载身份（workload identity）和 OpenID Connect (OIDC)。可参考指南。

先为 CAA 创建一个身份：

export AZURE_WORKLOAD_IDENTITY_NAME="${CLUSTER_NAME}-identity"

az identity create \
  --name "${AZURE_WORKLOAD_IDENTITY_NAME}" \
  --resource-group "${AZURE_RESOURCE_GROUP}" \
  --location "${AZURE_REGION}"

export USER_ASSIGNED_CLIENT_ID="$(az identity show \
  --resource-group "${AZURE_RESOURCE_GROUP}" \
  --name "${AZURE_WORKLOAD_IDENTITY_NAME}" \
  --query 'clientId' \
  -otsv)"

网络

承载 Pod 的虚拟机通常需要访问互联网服务，例如从公共 OCI 镜像仓库拉取镜像。你可以在 AKS 集群所在 VNet 中，为 AKS 子网旁边新建一个独立子网，再为该子网绑定带公网 IP 的 NAT 网关：

export AZURE_VNET_NAME="$(az network vnet list -g ${AKS_RG} --query '[].name' -o tsv)"
export AKS_CIDR="$(az network vnet show -n $AZURE_VNET_NAME -g $AKS_RG --query "subnets[?name == 'aks-subnet'].addressPrefix" -o tsv)"
# 10.224.0.0/16
export MASK="${AKS_CIDR#*/}"
# 16
PEERPOD_CIDR="$(sipcalc $AKS_CIDR -n 2 | grep ^Network | grep -v current | cut -d' ' -f2)/${MASK}"
# 10.225.0.0/16
az network public-ip create -g "$AKS_RG" -n peerpod
az network nat gateway create -g "$AKS_RG" -l "$AZURE_REGION" --public-ip-addresses peerpod -n peerpod
az network vnet subnet create -g "$AKS_RG" --vnet-name "$AZURE_VNET_NAME" --nat-gateway peerpod --address-prefixes "$PEERPOD_CIDR" -n peerpod
export AZURE_SUBNET_ID="$(az network vnet subnet show -g "$AKS_RG" --vnet-name "$AZURE_VNET_NAME" -n peerpod --query id -o tsv)"

AKS 资源组权限

为了让 CAA 能管理虚拟机，需为该身份授予虚拟机和网络相关权限，使其能够在 $AZURE_RESOURCE_GROUP 中创建虚拟机，并连接 $AKS_RG 中的 VNet。

az role assignment create \
  --role "Virtual Machine Contributor" \
  --assignee "$USER_ASSIGNED_CLIENT_ID" \
  --scope "/subscriptions/${AZURE_SUBSCRIPTION_ID}/resourcegroups/${AZURE_RESOURCE_GROUP}"

az role assignment create \
  --role "Reader" \
  --assignee "$USER_ASSIGNED_CLIENT_ID" \
  --scope "/subscriptions/${AZURE_SUBSCRIPTION_ID}/resourcegroups/${AZURE_RESOURCE_GROUP}"

az role assignment create \
  --role "Network Contributor" \
  --assignee "$USER_ASSIGNED_CLIENT_ID" \
  --scope "/subscriptions/${AZURE_SUBSCRIPTION_ID}/resourcegroups/${AKS_RG}"

使用 AKS 集群的 OIDC endpoint 为 CAA ServiceAccount 创建联合凭证：

export AKS_OIDC_ISSUER="$(az aks show \
  --name "${CLUSTER_NAME}" \
  --resource-group "${AZURE_RESOURCE_GROUP}" \
  --query "oidcIssuerProfile.issuerUrl" \
  -otsv)"

az identity federated-credential create \
  --name "${CLUSTER_NAME}-federated" \
  --identity-name "${AZURE_WORKLOAD_IDENTITY_NAME}" \
  --resource-group "${AZURE_RESOURCE_GROUP}" \
  --issuer "${AKS_OIDC_ISSUER}" \
  --subject system:serviceaccount:confidential-containers-system:cloud-api-adaptor \
  --audience api://AzureADTokenExchange

部署 CAA Helm Chart

说明： 如果你的 Kubernetes 集群使用 Calico Container Network Interface (CNI)，请先按说明为所有工作负载间流量配置 Virtual Extensible LAN (VXLAN) 封装。

下载 CAA Helm 部署资源

• 版本：
• 最新发布
• 最新构建
• DIY

CAA_VERSION="$(
  curl -fsSL \
    "https://api.github.com/repos/confidential-containers/cloud-api-adaptor/releases/latest" |
    jq -er '.tag_name | sub("^v"; "")'
)"
curl -LO "https://github.com/confidential-containers/cloud-api-adaptor/archive/refs/tags/v${CAA_VERSION}.tar.gz"
tar -xvzf "v${CAA_VERSION}.tar.gz"
cd "cloud-api-adaptor-${CAA_VERSION}/src/cloud-api-adaptor/install/charts/peerpods"

export CAA_BRANCH="main"
curl -LO "https://github.com/confidential-containers/cloud-api-adaptor/archive/refs/heads/${CAA_BRANCH}.tar.gz"
tar -xvzf "${CAA_BRANCH}.tar.gz"
cd "cloud-api-adaptor-${CAA_BRANCH}/src/cloud-api-adaptor/install/charts/peerpods"

导出 PodVM 镜像版本

导出 peer pods 所用的 PodVM 镜像 ID。该变量告诉部署工具在 Azure 中创建 peer pod 虚拟机时应使用哪个 PodVM 镜像版本。

镜像来自 CoCo 社区镜像库（或由你手动构建），并且必须与当前 CAA 发布版本匹配。

• 版本：
• 最新发布
• 最新构建
• DIY

export AZURE_IMAGE_ID="/CommunityGalleries/cococommunity-42d8482d-92cd-415b-b332-7648bd978eff/Images/peerpod-podvm-fedora/Versions/${CAA_VERSION}"

SUCCESS_TIME=$(curl -s \
  -H "Accept: application/vnd.github+json" \
  "https://api.github.com/repos/confidential-containers/cloud-api-adaptor/actions/workflows/azure-nightly-build.yml/runs?status=success" \
  | jq -r '.workflow_runs[0].updated_at')

export AZURE_IMAGE_ID="/CommunityGalleries/cocopodvm-d0e4f35f-5530-4b9c-8596-112487cdea85/Images/podvm_image0/Versions/$(date -u -jf "%Y-%m-%dT%H:%M:%SZ" "$SUCCESS_TIME" "+%Y.%m.%d" 2>/dev/null || date -d "$SUCCESS_TIME" +%Y.%m.%d)"

导出 CAA 容器镜像路径

定义要部署的 Cloud API Adaptor（CAA）容器镜像。 这些变量指定了部署工具所要拉取和运行的 CAA 镜像及其架构专属 tag。 tag 与 CAA 发布版本对应，以确保与所选 PodVM 镜像和配置兼容。

• 版本：
• 最新发布
• 最新构建
• DIY

export CAA_IMAGE="quay.io/confidential-containers/cloud-api-adaptor"
export CAA_TAG="v${CAA_VERSION}-amd64"

export CAA_IMAGE="quay.io/confidential-containers/cloud-api-adaptor"

export CAA_TAG=""

选择 peer-pods 机型

• AMD SEV-SNP
• Intel TDX
• 非机密计算

export AZURE_INSTANCE_SIZE="Standard_DC2as_v5"
export DISABLECVM="false"

export AZURE_INSTANCE_SIZE="Standard_DC2es_v6"
export DISABLECVM="false"

export AZURE_INSTANCE_SIZE="Standard_D2as_v5"
export DISABLECVM="true"

填充 providers/azure.yaml 文件

全部可用配置项可在以下两个位置找到：

• 主 chart values
• Azure 专属 values

运行以下命令更新 providers/azure.yaml 文件：

cat <<EOF > providers/azure.yaml
provider: azure
image:
  name: "${CAA_IMAGE}"
  tag: "${CAA_TAG}"
providerConfigs:
   azure:
      AZURE_IMAGE_ID: "${AZURE_IMAGE_ID}"
      AZURE_REGION: "${AZURE_REGION}"
      AZURE_RESOURCE_GROUP: "${AZURE_RESOURCE_GROUP}"
      AZURE_SUBNET_ID: "${AZURE_SUBNET_ID}"
      AZURE_SUBSCRIPTION_ID: "${AZURE_SUBSCRIPTION_ID}"
      AZURE_INSTANCE_SIZE: "${AZURE_INSTANCE_SIZE}"
      DISABLECVM: ${DISABLECVM}
EOF

在 Kubernetes 集群中部署 Helm Chart

1. 创建由 Helm 管理的命名空间：

   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. 使用 kubectl 创建 Secret：

   所需 key 请参见 providers/azure-secrets.yaml.template。

说明： 以下示例假定你使用工作负载身份（workload identity）进行认证，因此不需要提供 AZURE_CLIENT_SECRET 和 AZURE_TENANT_ID。

kubectl create secret generic my-provider-creds \
 -n confidential-containers-system \
 --from-literal=AZURE_CLIENT_ID="${USER_ASSIGNED_CLIENT_ID}" \
 --from-file=id_rsa.pub=${SSH_KEY}

说明： --from-file=id_rsa.pub=${SSH_KEY} 是可选项。它允许用户为排障目的通过 SSH 登录 PodVM。 该选项只对启用了调试功能的自定义 PodVM 镜像有效。预构建的 PodVM 镜像默认不启用 SSH 连接。

3. 安装 Helm Chart：

   下面命令使用了 -f 和 --set 这两个自定义选项，其含义可参考这里。

   helm install peerpods . \
     -f providers/azure.yaml \
     --set secrets.mode=reference \
     --set secrets.existingSecretName=my-provider-creds \
     --set-json daemonset.podLabels='{"azure.workload.identity/use":"true"}' \
     --dependency-update \
     -n confidential-containers-system
   

说明： 上述示例假定你使用工作负载身份（workload identity）进行认证。
--set-json daemonset.podLabels='{{"azure.workload.identity/use":"true"}}' 参数仅在使用工作负载身份时才需要。

通用的 Peer Pods Helm Chart 部署说明也可参考这里。

运行示例应用

确认 RuntimeClass 已创建

部署 Peer Pods Helm Chart 后，请确认已创建 runtimeclass：

kubectl get runtimeclass

当你看到名为 kata-remote 的 runtimeclass 时，就说明部署成功。 成功输出类似如下：

$ kubectl get runtimeclass
NAME          HANDLER       AGE
kata-remote   kata-remote   7m18s

部署工作负载

创建一个 nginx deployment：

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      runtimeClassName: kata-remote
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        imagePullPolicy: Always
EOF

确认 pod 已成功启动：

kubectl get pods -n default

你可以通过运行以下命令确认 peer pod VM 是否已经创建：

az vm list \
  --resource-group "${AZURE_RESOURCE_GROUP}" \
  --output table

此时你应该能看到与 pod nginx 对应的虚拟机。

说明： 如果遇到问题，请查看故障排查指南。

PodVM 参考值

PodVM 镜像在构建过程中，会把预期的 PCR 测量值发布到 OCI 镜像仓库中。

前提条件

安装 ORAS 工具，以便从 OCI 镜像仓库拉取参考值；安装 GitHub CLI，以便验证构建来源。

验证构建来源

确认这些测量值是由官方仓库中可信的构建流程生成的。指定 --format=json 可以看到更详细的构建信息。

CAA_REPO="confidential-containers/cloud-api-adaptor"
OCI_REGISTRY="ghcr.io/${CAA_REPO}/measurements/azure/podvm:${CAA_VERSION}"
gh attestation verify -R "$CAA_REPO" "oci://${OCI_REGISTRY}"

获取参考值

这些 PCR 值可用于远程证明策略中，以校验 PodVM 镜像的完整性。

oras pull "$OCI_REGISTRY"
jq -r .measurements.sha256.pcr11 < measurements.json
0x58e8afdf5b105fc6b202eb8e537a9f1512a4b33cd5921171b518645a86ca5a75

清理

如果你希望清理整个环境，可以运行以下命令删除资源组：

az group delete \
  --name "${AZURE_RESOURCE_GROUP}" \
  --yes --no-wait

4.3 - Google Cloud Platform (GCP)

说明： 本文为英文文档的中文译版，英文原版请参见 GCP 示例（英文版）。

本文将介绍如何在 Google Kubernetes Engine (GKE) 上配置 CAA（即 Peer Pods），具体包括：

• 一个基于 GKE 的单工作节点 Kubernetes 集群
• 运行在该 Kubernetes 集群上的 CAA
• 一个由 CAA PodVM 支持的示例应用

前提条件

安装所需工具：

• 安装 kubectl
• 安装 Helm
• 安装 gcloud CLI 工具

Google Cloud 项目：

• 确保你已经创建了一个 Google Cloud 项目
• 记录项目 ID（导出为 GCP_PROJECT_ID）

GCP 准备工作

先完成 Google 认证，并选择要使用的项目：

export GCP_PROJECT_ID="YOUR_PROJECT_ID"
gcloud auth login
gcloud config set project ${GCP_PROJECT_ID}

启用所需 API：

gcloud services enable container.googleapis.com --project=${GCP_PROJECT_ID}

创建一个具备所需权限的服务账号：

gcloud iam service-accounts create peerpods \
  --description="Peerpods Service Account" \
  --display-name="Peerpods Service Account"

gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="serviceAccount:peerpods@${GCP_PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/compute.instanceAdmin.v1"

gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="serviceAccount:peerpods@${GCP_PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/iam.serviceAccountUser"

生成并保存凭证文件：

gcloud iam service-accounts keys create \
  ~/.config/gcloud/peerpods_application_key.json \
  --iam-account=peerpods@${GCP_PROJECT_ID}.iam.gserviceaccount.com

export GOOGLE_APPLICATION_CREDENTIALS=~/.config/gcloud/peerpods_application_key.json

配置后续要使用的其他环境变量。

设置区域：

export GCP_REGION="us-central1"

设置 PodVM 实例类型：

• AMD SEV-SNP
• Intel TDX
• 非机密计算

export PODVM_INSTANCE_TYPE="n2d-standard-4"
export DISABLECVM=false
export GCP_CONFIDENTIAL_TYPE="SEV" # SEV or SEV_SNP
export GCP_DISK_TYPE="pd-standard"

export PODVM_INSTANCE_TYPE="c3-standard-4"
export DISABLECVM=false
export GCP_CONFIDENTIAL_TYPE="TDX"
export GCP_DISK_TYPE="pd-balanced"

export PODVM_INSTANCE_TYPE="e2-medium"
export DISABLECVM=true
export GCP_CONFIDENTIAL_TYPE=""
export GCP_DISK_TYPE="pd-standard"

使用 GKE 部署 Kubernetes

使用 GKE 部署一个单节点 Kubernetes 集群：

gcloud container clusters create my-cluster \
  --zone ${GCP_REGION}-a \
  --machine-type "e2-standard-4" \
  --image-type UBUNTU_CONTAINERD \
  --num-nodes 1

为工作节点添加标签：

kubectl get nodes --selector='!node-role.kubernetes.io/master' -o name | \
xargs -I{} kubectl label {} node.kubernetes.io/worker=

配置 VPC 网络

我们需要确保默认 VPC 网络中已经放通 15150 端口：

gcloud compute firewall-rules create allow-port-15150 \
    --project=${GCP_PROJECT_ID} \
    --network=default \
    --allow=tcp:15150

在生产场景中，建议限制来源 IP 范围，以降低安全风险。例如，可以把来源范围限制为特定 IP 地址或 CIDR 段：

gcloud compute firewall-rules create allow-port-15150-restricted \
   --project=${GCP_PROJECT_ID} \
   --network=default \
   --allow=tcp:15150 \
   --source-ranges=[YOUR_EXTERNAL_IP]

部署 CAA Helm Chart

下载 CAA Helm 部署资源

• 版本：
• 最新发布
• 最新构建
• DIY

CAA_VERSION="$(
  curl -fsSL \
    "https://api.github.com/repos/confidential-containers/cloud-api-adaptor/releases/latest" |
    jq -er '.tag_name | sub("^v"; "")'
)"
curl -LO "https://github.com/confidential-containers/cloud-api-adaptor/archive/refs/tags/v${CAA_VERSION}.tar.gz"
tar -xvzf "v${CAA_VERSION}.tar.gz"
cd "cloud-api-adaptor-${CAA_VERSION}/src/cloud-api-adaptor/install/charts/peerpods"

export CAA_BRANCH="main"
curl -LO "https://github.com/confidential-containers/cloud-api-adaptor/archive/refs/heads/${CAA_BRANCH}.tar.gz"
tar -xvzf "${CAA_BRANCH}.tar.gz"
cd "cloud-api-adaptor-${CAA_BRANCH}/src/cloud-api-adaptor/install/charts/peerpods"

导出 PodVM 镜像版本

导出 peer pods 所用的 PodVM 镜像 ID。该变量告诉部署工具在 Google Cloud 中创建 peer pod 虚拟机时应使用哪个 PodVM 镜像版本。

镜像来自 CoCo 社区镜像库（或由你手动构建），并且必须与当前 CAA 发布版本匹配。

• 版本：
• 最新发布
• 最新构建
• DIY

export PODVM_IMAGE_ID="/projects/it-cloud-gcp-prod-osc-devel/global/images/fedora-mkosi-tee-amd-1-11-0"

导出 CAA 容器镜像路径

定义要部署的 Cloud API Adaptor（CAA）容器镜像。 这些变量指定了部署工具所要拉取和运行的 CAA 镜像及其架构专属 tag。 tag 与 CAA 发布版本对应，以确保与所选 PodVM 镜像和配置兼容。

• 版本：
• 最新发布
• 最新构建
• DIY

export CAA_IMAGE="quay.io/confidential-containers/cloud-api-adaptor"
export CAA_TAG="v${CAA_VERSION}-amd64"

export CAA_IMAGE="quay.io/confidential-containers/cloud-api-adaptor"

export CAA_TAG=""

填充 providers/gcp.yaml 文件

全部可用配置项可在以下两个位置找到：

• 主 chart values
• GCP 专属 values

运行以下命令更新 providers/gcp.yaml 文件：

cat <<EOF > providers/gcp.yaml
provider: gcp
image:
  name: "${CAA_IMAGE}"
  tag: "${CAA_TAG}"
providerConfigs:
  gcp:
    GCP_NETWORK: "global/networks/default"
    GCP_PROJECT_ID: "${GCP_PROJECT_ID}"
    GCP_ZONE: "${GCP_REGION}-a"
    GCP_MACHINE_TYPE: "${PODVM_INSTANCE_TYPE}"
    GCP_DISK_TYPE: "${GCP_DISK_TYPE}"
    PODVM_IMAGE_NAME: "${PODVM_IMAGE_ID}"
    GCP_CONFIDENTIAL_TYPE: "${GCP_CONFIDENTIAL_TYPE}"
    DISABLECVM: ${DISABLECVM}
EOF

在 Kubernetes 集群中部署 Helm Chart

1. 创建由 Helm 管理的命名空间：

   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. 使用 kubectl 创建 Secret：

   所需 key 请参见 providers/gcp-secrets.yaml.template。

   kubectl create secret generic my-provider-creds \
    -n confidential-containers-system \
    --from-file=GCP_CREDENTIALS="${GOOGLE_APPLICATION_CREDENTIALS}"
   

3. 安装 Helm Chart：

   下面命令使用了 -f 和 --set 这两个自定义选项，其含义可参考这里。

   helm install peerpods . \
     -f providers/gcp.yaml \
     --set secrets.mode=reference \
     --set secrets.existingSecretName=my-provider-creds \
     --dependency-update \
     -n confidential-containers-system
   

通用的 Peer Pods Helm Chart 部署说明也可参考这里。

运行示例应用

确认 RuntimeClass 已创建

部署 Peer Pods Helm Chart 后，请确认已创建 runtimeclass：

kubectl get runtimeclass

当你看到名为 kata-remote 的 runtimeclass 时，就说明部署成功。 成功输出类似如下：

$ kubectl get runtimeclass
NAME          HANDLER       AGE
kata-remote   kata-remote   7m18s

部署工作负载

• CoCo 机密获取
• 基础 nginx

# initdata.toml
algorithm = "sha384"
version = "0.1.0"

[data]
"aa.toml" = '''
[token_configs]
[token_configs.coco_as]
url = 'http://127.0.0.1:8080'

[token_configs.kbs]
url = 'http://127.0.0.1:8080'
cert = """
-----BEGIN CERTIFICATE-----
MIIDljCCAn6gAwIBAgIUR/UNh13GFam4emgludtype/S9BIwDQYJKoZIhvcNAQEL
BQAwdTELMAkGA1UEBhMCQ04xETAPBgNVBAgMCFpoZWppYW5nMREwDwYDVQQHDAhI
YW5nemhvdTERMA8GA1UECgwIQUFTLVRFU1QxFDASBgNVBAsMC0RldmVsb3BtZW50
MRcwFQYDVQQDDA5BQVMtVEVTVC1IVFRQUzAeFw0yNDAzMTgwNzAzNTNaFw0yNTAz
MTgwNzAzNTNaMHUxCzAJBgNVBAYTAkNOMREwDwYDVQQIDAhaaGVqaWFuZzERMA8G
A1UEBwwISGFuZ3pob3UxETAPBgNVBAoMCEFBUy1URVNUMRQwEgYDVQQLDAtEZXZl
bG9wbWVudDEXMBUGA1UEAwwOQUFTLVRFU1QtSFRUUFMwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDfp1aBr6LiNRBlJUcDGcAbcUCPG6UzywtVIc8+comS
ay//gwz2AkDmFVvqwI4bdp/NUCwSC6ShHzxsrCEiagRKtA3af/ckM7hOkb4S6u/5
ewHHFcL6YOUp+NOH5/dSLrFHLjet0dt4LkyNBPe7mKAyCJXfiX3wb25wIBB0Tfa0
p5VoKzwWeDQBx7aX8TKbG6/FZIiOXGZdl24DGARiqE3XifX7DH9iVZ2V2RL9+3WY
05GETNFPKtcrNwTy8St8/HsWVxjAzGFzf75Lbys9Ff3JMDsg9zQzgcJJzYWisxlY
g3CmnbENP0eoHS4WjQlTUyY0mtnOwodo4Vdf8ZOkU4wJAgMBAAGjHjAcMBoGA1Ud
EQQTMBGCCWxvY2FsaG9zdIcEfwAAATANBgkqhkiG9w0BAQsFAAOCAQEAKW32spii
t2JB7C1IvYpJw5mQ5bhIlldE0iB5rwWvNbuDgPrgfTI4xiX5sumdHw+P2+GU9KXF
nWkFRZ9W/26xFrVgGIS/a07aI7xrlp0Oj+1uO91UhCL3HhME/0tPC6z1iaFeZp8Y
T1tLnafqiGiThFUgvg6PKt86enX60vGaTY7sslRlgbDr9sAi/NDSS7U1PviuC6yo
yJi7BDiRSx7KrMGLscQ+AKKo2RF1MLzlJMa1kIZfvKDBXFzRd61K5IjDRQ4HQhwX
DYEbQvoZIkUTc1gBUWDcAUS5ztbJg9LCb9WVtvUTqTP2lGuNymOvdsuXq+sAZh9b
M9QaC1mzQ/OStg==
-----END CERTIFICATE-----
"""
'''

"cdh.toml"  = '''
socket = 'unix:///run/confidential-containers/cdh.sock'
credentials = []

[kbc]
name = 'cc_kbc'
url = 'http://1.2.3.4:8080'
kbs_cert = """
-----BEGIN CERTIFICATE-----
MIIFTDCCAvugAwIBAgIBADBGBgkqhkiG9w0BAQowOaAPMA0GCWCGSAFlAwQCAgUA
oRwwGgYJKoZIhvcNAQEIMA0GCWCGSAFlAwQCAgUAogMCATCjAwIBATB7MRQwEgYD
VQQLDAtFbmdpbmVlcmluZzELMAkGA1UEBhMCVVMxFDASBgNVBAcMC1NhbnRhIENs
YXJhMQswCQYDVQQIDAJDQTEfMB0GA1UECgwWQWR2YW5jZWQgTWljcm8gRGV2aWNl
czESMBAGA1UEAwwJU0VWLU1pbGFuMB4XDTIzMDEyNDE3NTgyNloXDTMwMDEyNDE3
NTgyNlowejEUMBIGA1UECwwLRW5naW5lZXJpbmcxCzAJBgNVBAYTAlVTMRQwEgYD
VQQHDAtTYW50YSBDbGFyYTELMAkGA1UECAwCQ0ExHzAdBgNVBAoMFkFkdmFuY2Vk
IE1pY3JvIERldmljZXMxETAPBgNVBAMMCFNFVi1WQ0VLMHYwEAYHKoZIzj0CAQYF
K4EEACIDYgAExmG1ZbuoAQK93USRyZQcsyobfbaAEoKEELf/jK39cOVJt1t4s83W
XM3rqIbS7qHUHQw/FGyOvdaEUs5+wwxpCWfDnmJMAQ+ctgZqgDEKh1NqlOuuKcKq
2YAWE5cTH7sHo4IBFjCCARIwEAYJKwYBBAGceAEBBAMCAQAwFwYJKwYBBAGceAEC
BAoWCE1pbGFuLUIwMBEGCisGAQQBnHgBAwEEAwIBAzARBgorBgEEAZx4AQMCBAMC
AQAwEQYKKwYBBAGceAEDBAQDAgEAMBEGCisGAQQBnHgBAwUEAwIBADARBgorBgEE
AZx4AQMGBAMCAQAwEQYKKwYBBAGceAEDBwQDAgEAMBEGCisGAQQBnHgBAwMEAwIB
CDARBgorBgEEAZx4AQMIBAMCAXMwTQYJKwYBBAGceAEEBEDDhCejDUx6+dlvehW5
cmmCWmTLdqI1L/1dGBFdia1HP46MC82aXZKGYSutSq37RCYgWjueT+qCMBE1oXDk
d1JOMEYGCSqGSIb3DQEBCjA5oA8wDQYJYIZIAWUDBAICBQChHDAaBgkqhkiG9w0B
AQgwDQYJYIZIAWUDBAICBQCiAwIBMKMDAgEBA4ICAQACgCai9x8DAWzX/2IelNWm
ituEBSiq9C9eDnBEckQYikAhPasfagnoWFAtKu/ZWTKHi+BMbhKwswBS8W0G1ywi
cUWGlzigI4tdxxf1YBJyCoTSNssSbKmIh5jemBfrvIBo1yEd+e56ZJMdhN8e+xWU
bvovUC2/7Dl76fzAaACLSorZUv5XPJwKXwEOHo7FIcREjoZn+fKjJTnmdXce0LD6
9RHr+r+ceyE79gmK31bI9DYiJoL4LeGdXZ3gMOVDR1OnDos5lOBcV+quJ6JujpgH
d9g3Sa7Du7pusD9Fdap98ocZslRfFjFi//2YdVM4MKbq6IwpYNB+2PCEKNC7SfbO
NgZYJuPZnM/wViES/cP7MZNJ1KUKBI9yh6TmlSsZZOclGJvrOsBZimTXpATjdNMt
cluKwqAUUzYQmU7bf2TMdOXyA9iH5wIpj1kWGE1VuFADTKILkTc6LzLzOWCofLxf
onhTtSDtzIv/uel547GZqq+rVRvmIieEuEvDETwuookfV6qu3D/9KuSr9xiznmEg
xynud/f525jppJMcD/ofbQxUZuGKvb3f3zy+aLxqidoX7gca2Xd9jyUy5Y/83+ZN
bz4PZx81UJzXVI9ABEh8/xilATh1ZxOePTBJjN7lgr0lXtKYjV/43yyxgUYrXNZS
oLSG2dLCK9mjjraPjau34Q==
-----END CERTIFICATE-----
"""
'''

"policy.rego" = '''
package agent_policy

import future.keywords.in
import future.keywords.every

import input

# Default values, returned by OPA when rules cannot be evaluated to true.
default CopyFileRequest := true
default CreateContainerRequest := true
default CreateSandboxRequest := true
default DestroySandboxRequest := true
default ExecProcessRequest := false
default GetOOMEventRequest := true
default GuestDetailsRequest := true
default OnlineCPUMemRequest := true
default PullImageRequest := true
default ReadStreamRequest := false
default RemoveContainerRequest := true
default RemoveStaleVirtiofsShareMountsRequest := true
default SignalProcessRequest := true
default StartContainerRequest := true
default StatsContainerRequest := true
default TtyWinResizeRequest := true
default UpdateEphemeralMountsRequest := true
default UpdateInterfaceRequest := true
default UpdateRoutesRequest := true
default WaitProcessRequest := true
default WriteStreamRequest := false
'''

INITDATA=$(cat initdata.toml | gzip | base64 -w0)

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    io.katacontainers.config.hypervisor.cc_init_data: "$INITDATA"
spec:
  runtimeClassName: kata-remote
  containers:
    - name: example-container
      image: alpine:latest
      command:
        - sleep
        - "3600"
      securityContext:
        privileged: false
        seccompProfile:
          type: RuntimeDefault
EOF

kubectl exec -it example-pod -- curl http://127.0.0.1:8006/cdh/resource/default/kbsres1/key1

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      runtimeClassName: kata-remote
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        imagePullPolicy: Always
EOF

确认 pod 已成功启动：

kubectl get pods -n default

你可以通过运行以下命令确认 PodVM 是否已经创建：

gcloud compute instances list

此时你应该能看到与上述示例 Pod 对应的虚拟机。

清理

删除所有使用 kata-remote RuntimeClass 运行的 Pod。可以使用以下命令：

kubectl get pods -A -o custom-columns='NAME:.metadata.name,NAMESPACE:.metadata.namespace,RUNTIMECLASS:.spec.runtimeClassName' | grep kata-remote | awk '{print $1, $2}'

确认所有 peer-pod VM 都已删除。你可以使用以下命令列出所有 peer-pod VM（名称前缀为 podvm）及其状态：

gcloud compute instances list \
  --filter="name~'podvm.*'" \
  --format="table(name,zone,status)"

运行以下命令删除 GKE 集群：

gcloud container clusters delete my-cluster --zone ${GCP_REGION}-a

故障排查

说明： 如果你的问题不在下面的范围内，请查看这里的故障排查指南。

虚拟机未启动

从 GKE 1.27 开始，GCP 会为 containerd 配置 discard_unpacked_layers=true，以节省磁盘空间（移除解包后的压缩镜像层）。但这可能会导致 PeerPods 出现问题，因为工作负载可能找不到所需镜像层。 为避免这个问题，请在 containerd 配置中禁用 discard_unpacked_layers。

大多数情况下，你会看到类似下面的通用报错：

Error: failed to create containerd container: error unpacking image: failed to extract layer sha256:<SHA>: failed to get reader from content store: content digest sha256:<SHA>: not found

要在 Google Kubernetes Engine (GKE) 1.27 及以上版本中禁用 containerd 配置里的 discard_unpacked_layers，请按以下步骤操作：

1. 在 Google Console 中 SSH 登录工作节点
2. 运行命令 sudo sed -i 's/discard_unpacked_layers = true/discard_unpacked_layers = false/' /etc/containerd/config.toml
3. 运行 sudo cat /etc/containerd/config.toml | grep discard_unpacked_layers 验证修改结果
4. 重启 containerd：sudo systemctl restart containerd

4.4 - 阿里云

说明： 本文为英文文档的中文译版，英文原版请参见阿里云示例（英文版）。

本文将介绍如何在阿里云容器服务 Kubernetes 版（ACK）和阿里云弹性计算服务（ECS）上部署 CAA（即 Peer Pods），具体包括：

• ACK 托管集群中的一个工作节点
• 运行在该 Kubernetes 集群上的 CAA
• 一个由运行在 ECS 上 CAA PodVM 支撑的 Nginx Pod

说明： 请在目录 src/cloud-api-adaptor 下运行以下命令。

说明： 当前机密计算实例已在部分地域提供。

说明： 阿里云官方文档可参考这里。

前提条件

安装所需工具：

• 安装 aliyun CLI 工具并配置凭证
• 准备一个带 Bucket 的 aliyun OSS 存储

创建 PodVM 镜像

说明： 在 cn-hongkong 地域中，版本 0.22.0 已提供一个预构建的社区镜像（id: m-j6c3kfz2vhu6ze04wacb），可直接用于测试。 也可以使用下方导出 PodVM 镜像版本中列出的各地域镜像 ID。

如果你希望自行构建 PodVM 镜像，请按以下步骤操作。当前 PodVM 构建使用 mkosi，目标系统为 Ubuntu 26.04（resolute）。前提条件和自定义选项请参见 PodVM README。

1. 构建 Ubuntu 26.04 PodVM 镜像。

   cd podvm
   make
   

   此命令将构建 PodVM 二进制文件和操作系统镜像，生成的 qcow2 文件路径为：

   podvm/build/podvm-ubuntu-amd64.qcow2
   

   若二进制文件已存在，仅重新构建操作系统镜像：

   cd podvm
   make image
   

2. 上传到 OSS，并创建 ECS 镜像。

   在 src/cloud-api-adaptor 目录下，将 qcow2 文件上传到 OSS（对象存储服务）：

   cd ..
   export REGION_ID=<region-id>
   export IMAGE_FILE=podvm/build/podvm-ubuntu-amd64.qcow2
   export BUCKET=<OSS-bucket-name>
   export OBJECT=<object-name>
   
   aliyun oss cp ${IMAGE_FILE} oss://${BUCKET}/${OBJECT}
   

   然后将该镜像文件导入为 ECS 镜像：

   export IMAGE_NAME=$(basename ${IMAGE_FILE%.*})
   aliyun ecs ImportImage --ImageName ${IMAGE_NAME} \
       --region ${REGION_ID} --RegionId ${REGION_ID} \
       --BootMode UEFI \
       --DiskDeviceMapping.1.OSSBucket ${BUCKET} --DiskDeviceMapping.1.OSSObject ${OBJECT} \
       --Features.NvmeSupport supported \
       --method POST --force
   
   export POD_IMAGE_ID=<ImageId>
   

构建 CAA 开发镜像

如果你希望自行构建 CAA DaemonSet 镜像：

export registry=<registry-address>
export RELEASE_BUILD=true
export CLOUD_PROVIDER=alibabacloud
make image

请记录该镜像使用的 tag，后续会用到。

使用 ACK 托管集群部署 Kubernetes

1. 创建 ACK 托管集群。

   export CONTAINER_CIDR=172.18.0.0/16
   export REGION_ID=cn-beijing
   export ZONES='["cn-beijing-i"]'
   
   aliyun cs CreateCluster --header "Content-Type=application/json" --body "
   {
     \"cluster_type\":\"ManagedKubernetes\",
     \"name\":\"caa\",
     \"region_id\":\"${REGION_ID}\",
     \"zone_ids\":${ZONES},
     \"enable_rrsa\":true,
     \"container_cidr\":\"${CONTAINER_CIDR}\",
     \"addons\":[
       {
         \"name\":\"flannel\"
       }
     ]
   }"
   
   export CLUSTER_ID=<cluster-id>
   export SECURITY_GROUP_ID=$(aliyun cs DescribeClusterDetail --ClusterId ${CLUSTER_ID} | jq -r ".security_group_id")
   

   等待集群创建完成。获取该集群的 vSwitch ID，然后为集群添加一个工作节点。

2. 为集群所在 VPC 添加公网访问能力。

   export VPC_ID=$(aliyun cs DescribeClusterDetail --ClusterId ${CLUSTER_ID} | jq -r ".vpc_id")
   export VSWITCH_ID=$(echo ${VSWITCH_IDS} | sed 's/[][]//g' | sed 's/"//g')
   aliyun vpc CreateNatGateway \
     --region ${REGION_ID} \
     --RegionId ${REGION_ID} \
     --VpcId ${VPC_ID} \
     --NatType Enhanced \
     --VSwitchId ${VSWITCH_ID} \
     --NetworkType internet
   
   export GATEWAY_ID="<NatGatewayId>"
   export SNAT_TABLE_ID="<SnatTableId>"
   
   # 公网 IP 带宽（Mbps）
   export BAND_WIDTH=5
   aliyun vpc AllocateEipAddress \
     --region ${REGION_ID} \
     --RegionId ${REGION_ID} \
     --Bandwidth ${BAND_WIDTH}
   
   export EIP_ID="<AllocationId>"
   export EIP_ADDRESS="<EipAddress>"
   
   aliyun vpc AssociateEipAddress \
     --region ${REGION_ID} \
     --RegionId ${REGION_ID} \
     --AllocationId ${EIP_ID} \
     --InstanceId ${GATEWAY_ID} \
     --InstanceType Nat
   
   aliyun vpc CreateSnatEntry \
     --region ${REGION_ID} \
     --RegionId ${REGION_ID} \
     --SnatTableId ${SNAT_TABLE_ID} \
     --SourceVSwitchId ${VSWITCH_ID} \
     --SnatIp ${EIP_ADDRESS}
   

3. 授予角色权限。

   为集群工作节点授予相应角色权限，使其能够创建 ECS 实例。

部署 CAA Helm Chart

下载 CAA Helm 部署资源

• 版本：
• 最新发布
• 最新构建
• DIY

CAA_VERSION="$(
  curl -fsSL \
    "https://api.github.com/repos/confidential-containers/cloud-api-adaptor/releases/latest" |
    jq -er '.tag_name | sub("^v"; "")'
)"
curl -LO "https://github.com/confidential-containers/cloud-api-adaptor/archive/refs/tags/v${CAA_VERSION}.tar.gz"
tar -xvzf "v${CAA_VERSION}.tar.gz"
cd "cloud-api-adaptor-${CAA_VERSION}/src/cloud-api-adaptor/install/charts/peerpods"

export CAA_BRANCH="main"
curl -LO "https://github.com/confidential-containers/cloud-api-adaptor/archive/refs/heads/${CAA_BRANCH}.tar.gz"
tar -xvzf "${CAA_BRANCH}.tar.gz"
cd "cloud-api-adaptor-${CAA_BRANCH}/src/cloud-api-adaptor/install/charts/peerpods"

导出 PodVM 镜像版本

导出 peer pods 所用的 PodVM 镜像 ID。该变量告诉部署工具在阿里云中创建 peer pod 虚拟机时应使用哪个 PodVM 镜像版本。

export IMAGEID="m-j6c3kfz2vhu6ze04wacb"

说明： 阿里云会预先构建这些镜像，不同地域使用不同的镜像 ID。

region	IMAGEID
cn-beijing	m-2ze2vxvrxsbue3sf8b02
cn-hongkong	m-j6c3kfz2vhu6ze04wacb
cn-hangzhou	m-bp146ws6x3iyuwjvbdw2
ap-southeast-1	m-t4ng1w8ipua3c0o57hor

导出 CAA 容器镜像路径

定义要部署的 Cloud API Adaptor（CAA）容器镜像。 这些变量指定了部署工具所要拉取和运行的 CAA 镜像及其架构专属 tag。 tag 与 CAA 发布版本对应，以确保与所选 PodVM 镜像和配置兼容。

• 版本：
• 最新发布
• 最新构建
• DIY

export CAA_IMAGE="quay.io/confidential-containers/cloud-api-adaptor"
export CAA_TAG="v${CAA_VERSION}-amd64"

export CAA_IMAGE="quay.io/confidential-containers/cloud-api-adaptor"

export CAA_TAG=""

选择 peer-pods 机型

export PODVM_INSTANCE_TYPE="ecs.g8i.xlarge"
export DISABLECVM="false"

说明： 更多支持机密计算的实例规格，请参考官方文档。

填充 providers/alibabacloud.yaml 文件

全部可用配置项可在以下两个位置找到：

• 主 chart values
• 阿里云专属 values

运行以下命令更新 providers/alibabacloud.yaml 文件：

cat <<EOF > providers/alibabacloud.yaml
provider: alibabacloud
image:
  name: "${CAA_IMAGE}"
  tag: "${CAA_TAG}"
providerConfigs:
   alibabacloud:
      IMAGEID: "${IMAGEID}"
      REGION: "${REGION_ID}"
      SECURITY_GROUP_IDS: "${SECURITY_GROUP_ID}"
      VSWITCH_ID: "${VSWITCH_ID}"
      DISABLECVM: ${DISABLECVM}
alibabacloud:
  rrsa:
    enable: true
EOF

说明： 如果你不使用 RRSA 进行认证，请将 yaml 中的 alibabacloud.rrsa.enable 改为 false。

在 Kubernetes 集群中部署 Helm Chart

1. 创建由 Helm 管理的命名空间：

   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. 使用 kubectl 创建 Secret：

   所需 key 请参见 providers/alibabacloud-secrets.yaml.template。

   说明： 以下示例假定你使用 RRSA 进行认证，因此不需要提供 ALIBABACLOUD_ACCESS_KEY_ID 和 ALIBABACLOUD_ACCESS_KEY_SECRET，而是提供 ALIBABA_CLOUD_ROLE_ARN 和 ALIBABA_CLOUD_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
   

3. 安装 Helm Chart：

   下面命令使用了 -f 和 --set 这两个自定义选项，其含义可参考这里。

   helm install peerpods . \
     -f providers/alibabacloud.yaml \
     --set secrets.mode=reference \
     --set secrets.existingSecretName=my-provider-creds \
     --dependency-update \
     -n confidential-containers-system
   

通用的 Peer Pods Helm Chart 部署说明也可参考这里。

运行示例应用

确认 runtimeclass 已创建

部署 CAA 后，请确认 runtimeclass 已创建：

kubectl get runtimeclass

当你看到名为 kata-remote 的 RuntimeClass 时，就说明部署成功。成功输出类似如下：

$ kubectl get runtimeclass
NAME          HANDLER       AGE
kata-remote   kata-remote   7m18s

部署工作负载

创建一个 nginx deployment：

echo '
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  runtimeClassName: kata-remote
  containers:
  - name: nginx
    image: registry.openanolis.cn/openanolis/nginx:1.14.1-8.6
' | kubectl apply -f -

确认 pod 已成功启动：

kubectl get pods -n default

你可以通过运行以下命令确认 peer-pod VM 是否已经创建：

aliyun ecs DescribeInstances --RegionId ${REGION_ID} --InstanceName 'podvm-*'

此时你应该能看到与 pod nginx 对应的虚拟机。 如果遇到问题，请查看故障排查指南。

远程证明

TODO

清理

删除所有使用 runtimeClass kata-remote 运行的 Pod。

确认所有 peer-pod VM 都已删除。你可以使用以下命令列出所有 peer-pod VM（名称前缀为 podvm）及其状态：

aliyun ecs DescribeInstances --RegionId ${REGION_ID} --InstanceName 'podvm-*'

运行以下命令删除 ACK 集群：

aliyun cs DELETE /clusters/${CLUSTER_ID} --region ${REGION_ID} --keep_slb false --retain_all_resources false --header "Content-Type=application/json;" --body "{}"

5 - NVIDIA GPU 示例

说明： 本文为英文文档的中文译版，英文原版请参见 NVIDIA GPU examples。

本文展示如何在 Pod 中配置 NVIDIA 设备直通。

配置前提是你已经按照 NVIDIA Confidential Containers Reference Architecture 部署了 CoCo，并且所用组件版本与下文的直通模式相匹配。若你想看一个把 GPU runtime class、Trustee/KBS、sealed secret、guest pull 和与之对应生成的 agent policy 串成完整 NIM 场景，可参考 带 GPU 远程证明的 NVIDIA NIM 部署场景。

简要说明如下：NVIDIA Hopper、NVIDIA Blackwell 和 NVIDIA RTX Pro 6000 都支持单 GPU 直通（SPT）。Hopper 和 Blackwell 另外支持多 GPU 场景（ PPCIE 和 MPT ）。Protected PCIe（PPCIE）只用于 Hopper 多 GPU，并且要求 NVLink switch 进入 PPCIE 模式，注意这里 CoCo 会帮你实现。多 GPU 直通（Multi-GPU Passthrough, MPT）用于 Blackwell GPU 之间的端到端加密。NVIDIA RTX Pro 不支持多 GPU 配置。下面分别给出各场景下 Pod 的配置。

1. Hopper、Blackwell 或 RTX Pro 6000 BSE：单 GPU 直通（SPT）

在默认的 Confidential Containers / GPU Operator 配置下（on），不需要修改 nvidia.com/cc.mode。

下面的 Pod 示例会在 Hopper、Blackwell 或 RTX Pro 6000 BSE 上申请 1 张 GPU：

apiVersion: v1
kind: Pod
metadata:
  name: cuda-vectoradd-kata
  namespace: default
spec:
  runtimeClassName: kata-qemu-nvidia-gpu-tdx
  restartPolicy: Never
  containers:
  - name: cuda-vectoradd
    image: "nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04"
    resources:
      limits:
        nvidia.com/pgpu: "1"

2. Blackwell（B200、B300）：多 GPU 直通（MPT）

Pod 其他部分不变，只需要把资源配置改成：

    resources:
      limits:
        nvidia.com/pgpu: "8"

3. Hopper：带 Protected PCIe（PPCIE）和 NVSwitch 的多 GPU 直通

在 Hopper 上，多 GPU 机密直通使用 Protected PCIe。也就是说，Pod 必须同时申请 GPU 和 NVSwitch 设备，节点也必须切到 ppcie 机密 GPU 模式。

kubectl label node <node-name> nvidia.com/cc.mode=ppcie --overwrite

Pod 其他部分仍然保持不变，只需要把资源段改成如下配置，把节点上的 GPU 与 NVSwitch 分配给 Pod：

    resources:
      limits:
        nvidia.com/pgpu: "8"
        nvidia.com/nvswitch: "4"

修改 nvidia.com/cc.mode 之后，等待 GPU Operator 相关组件重新稳定，并确认 Pod 状态正常（kubectl get pods -A）。可参考 Kata QEMU GPU guide 的做法。

如果要恢复为单 GPU 直通，把标签改回 on：

kubectl label node <node-name> nvidia.com/cc.mode=on --overwrite

6 - NVIDIA 机密 NIM 部署

说明： 本文为英文文档的中文译版，英文原版请参见 NVIDIA confidential NIM deployment。

本文演示如何把 NVIDIA NIM 推理工作负载部署到 Kubernetes，并运行在 Confidential Containers 上。这里以一台启用了 NVIDIA GPU 机密计算能力的 AMD SEV-SNP Kubernetes 工作节点为例。相同的方法也可以迁移到 Intel TDX 节点，但参考值与证明策略需要按 TDX 重新生成，本文不展开。

NVIDIA NIM 将基础模型封装成容器，并提供针对 GPU 优化的运行时与 HTTP API。本文从一个普通的 NIM Pod 清单开始，镜像为 nvcr.io/nim/meta/llama-3.1-8b-instruct:1.13.1，通过 chat completions API 提供 Meta Llama 3.1 8B Instruct 模型服务。可选的基线步骤会先用非机密的 kata-qemu-nvidia-gpu runtime class 启动它，并检查 8000 端口上的健康状态、模型列表与推理接口。机密场景则切换为 kata-qemu-nvidia-gpu-snp runtime class，把 Pod 放进机密虚拟机中；但仅改 runtime class 还不够，还需要补齐 Trustee 的 KBS、guest pull、AA 与 CDH 配置、sealed secret、镜像签名策略、生成的 Kata agent policy、可信存储，以及批准 CPU、GPU 与 initdata 证据的 KBS 策略。下面按 checkpoint 逐步完成这些配置。

前提条件

开始前请准备：

• 一个已经部署好 Confidential Containers、Kata、NVIDIA GPU Operator，并提供机密 GPU runtime class（例如 kata-qemu-nvidia-gpu-snp）的 Kubernetes 集群。可参考 NVIDIA Confidential Containers deployment guide
• 可访问 Kubernetes 工作节点，因为本文需要从在线 QEMU 进程中收集 SNP 启动输入
• 一个可拉取 NIM 镜像的 NGC API key
• 工作节点上安装好 kubectl、curl、jq、openssl、oras、skopeo、envsubst、base64、tar、zstd 和 cargo
• 工作节点上安装 Docker 及 Docker Compose 插件
• 工作节点上安装 Python 包 cryptography 和 jwcrypto，后面生成 sealed secret 辅助脚本会用到

流程概览

本文把机密部署拆成一组可逐步验证的 checkpoints。每完成一步，都应能看到当前状态并在继续前修正问题。

1. 可选：非机密基线验证：把 GPU 切到非机密模式，部署基线 Pod，确认 NIM API 可用，删除 Pod，再把 GPU 切回机密模式。
2. 部署 Trustee 并安装 kbs-client：在节点上直接部署 Trustee，选择匹配的 Trustee 版本，配置 KBS HTTPS 端点，并准备 KBS。
3. 准备 TEE NIM 清单与 sealed secret：生成运行时密钥对应的 sealed secret，定义引用该密钥、镜像拉取 Secret 与可信存储的 SNP GPU Pod 清单。
4. 创建 Pod initdata 注解：为 AA 和 CDH 配置 KBS 地址、KBS 证书、镜像仓库凭据 URI 以及镜像签名策略 URI。
5. 生成 Kata agent policy：对 TEE Pod 清单运行 genpolicy，把策略与 initdata 合并，写回生成的 cc_init_data 注解，并保留生成后的清单但暂不部署。
6. 收集 SNP 启动参考值：如果还没有现成的参考值，就用生成好的 cc_init_data 启动一个轻量级度量 Pod，记录 SNP launch measurement、SNP TCB 值以及已证明的 initdata 摘要，然后删除测量 Pod。
7. 写入 KBS 资源、参考值与策略：配置 NVIDIA 镜像签名校验、公有镜像仓库凭据、NIM 运行时 API key、SNP 参考值、sealed secret 验证公钥，以及要求 CPU、GPU 证据和 initdata 摘要都匹配的 KBS 策略。
8. 准备可信存储资源：创建 TEE NIM Pod 所依赖的可信存储。
9. 运行端到端场景：创建 Kubernetes 侧的 Secret，部署带策略的 TEE NIM 清单，并验证在 KBS 策略约束下 NIM API 仍可正常访问。

初始 NIM Manifest

先导出一个可拉取 NIM 镜像的 NGC API key，然后生成初始清单模板。如果你不做 checkpoint 1 的非机密基线验证，那么这个步骤不需要实际部署。

这个 Manifest 会在两个地方使用 NGC API key：ngc-secret-instruct 供 Kubernetes 从 nvcr.io 拉取镜像，ngc-api-key-instruct 则把 key 传给 NIM 容器在运行时使用。为了简化示例，本文复用了同一个 key。实际环境中，建议把镜像拉取与容器运行时使用的 key 分开。

该文件是可选基线部署的基础 Manifest。它保留 ${NGC_API_KEY} 作为占位符，后面的校验和部署命令会通过 envsubst 把它替换后再交给 kubectl。

export NGC_API_KEY="<NGC_API_KEY>"

cat <<'EOF' | tee nvidia-nim-llama-3-1-8b-instruct.yaml >/dev/null
apiVersion: v1
kind: Secret
metadata:
  name: ngc-secret-instruct
type: kubernetes.io/dockerconfigjson
stringData:
  .dockerconfigjson: |
    {
      "auths": {
        "nvcr.io": {
          "username": "$oauthtoken",
          "password": "${NGC_API_KEY}"
        }
      }
    }
---
apiVersion: v1
kind: Secret
metadata:
  name: ngc-api-key-instruct
type: Opaque
stringData:
  api-key: "${NGC_API_KEY}"
---
apiVersion: v1
kind: Pod
metadata:
  name: nvidia-nim-llama-3-1-8b-instruct
  labels:
    app: nvidia-nim-llama-3-1-8b-instruct
spec:
  restartPolicy: Never
  runtimeClassName: kata-qemu-nvidia-gpu
  imagePullSecrets:
    - name: ngc-secret-instruct
  containers:
    - name: nvidia-nim-llama-3-1-8b-instruct
      image: nvcr.io/nim/meta/llama-3.1-8b-instruct:1.13.1
      ports:
        - containerPort: 8000
          name: http-openai
      livenessProbe:
        httpGet:
          path: /v1/health/live
          port: http-openai
        initialDelaySeconds: 15
        periodSeconds: 10
        timeoutSeconds: 1
        successThreshold: 1
        failureThreshold: 3
      readinessProbe:
        httpGet:
          path: /v1/health/ready
          port: http-openai
        initialDelaySeconds: 15
        periodSeconds: 10
        timeoutSeconds: 1
        successThreshold: 1
        failureThreshold: 3
      startupProbe:
        httpGet:
          path: /v1/health/ready
          port: http-openai
        initialDelaySeconds: 360
        periodSeconds: 10
        timeoutSeconds: 1
        successThreshold: 1
        failureThreshold: 120
      env:
        - name: NGC_API_KEY
          valueFrom:
            secretKeyRef:
              name: ngc-api-key-instruct
              key: api-key
      resources:
        limits:
          nvidia.com/pgpu: "1"
          cpu: "16"
          memory: "48Gi"
EOF

Checkpoint 1：可选的非机密基线验证

如果你只关心机密部署，可以跳过这一节。这里的作用只是先验证普通 NIM Pod 在 Kata Containers 上能否正常运行。流程是：临时把 GPU 切到非机密模式，运行非 TEE Pod，验证后删除，再切回机密模式。

这里通过节点标签触发模式切换，NVIDIA GPU Operator 会根据标签完成相应编排。最后一定要把节点切回机密 GPU 模式，后续 checkpoint 才能继续。关于 GPU runtime class 和机密 GPU 模式标签，可参考 NVIDIA GPU 示例。

先确保节点处于 VM passthrough 和非机密 GPU 模式：

kubectl label nodes --all \
  nvidia.com/gpu.workload.config=vm-passthrough \
  --overwrite

kubectl label nodes --all nvidia.com/cc.mode=off --overwrite

切换 CC 模式时，GPU Operator 的一些组件可能会重启。先等待节点标签确认模式切换完成，再等待 GPU Operator 相关控制器稳定。这里不要直接等所有 Pod 全部就绪，因为模式切换期间 operator 可能会删除并重建一部分 Pod。

kubectl wait \
  --for=jsonpath='{.metadata.labels.nvidia\.com/cc\.mode\.state}'=off \
  node --all \
  --timeout=15m

kubectl -n gpu-operator wait \
  --for=condition=Available \
  deployment --all \
  --timeout=10m

kubectl -n gpu-operator rollout status \
  daemonset/nvidia-vfio-manager \
  --timeout=10m

kubectl -n gpu-operator rollout status \
  daemonset/nvidia-sandbox-validator \
  --timeout=10m

kubectl -n gpu-operator rollout status \
  daemonset/nvidia-kata-sandbox-device-plugin-daemonset \
  --timeout=10m

kubectl -n gpu-operator rollout status \
  daemonset/nvidia-cc-manager \
  --timeout=10m

kubectl get nodes \
  -L nvidia.com/gpu.workload.config,nvidia.com/cc.mode,nvidia.com/cc.mode.state

部署非机密模式：

: "${NGC_API_KEY:?set NGC_API_KEY to your NGC API key}"

envsubst '${NGC_API_KEY}' \
  < nvidia-nim-llama-3-1-8b-instruct.yaml \
  | kubectl apply -f -

kubectl wait --for=condition=Ready \
  --timeout=600s \
  pod/nvidia-nim-llama-3-1-8b-instruct

演示环境里，直接从能访问集群 Pod 网络的机器上查询 Pod IP，例如单节点集群宿主机。这一步不会创建 Kubernetes Service。生产环境通常会通过 Service、Ingress、Gateway 或其他受控入口暴露 NIM。

检查 NIM 是否就绪并列出模型名：

POD_IP="$(kubectl get pod nvidia-nim-llama-3-1-8b-instruct -o jsonpath='{.status.podIP}')"

curl -fsS "http://${POD_IP}:8000/v1/health/ready" | jq .
curl -fsS "http://${POD_IP}:8000/v1/models" | jq -r '.data[].id'

发送一个最简单的 chat completion 请求：

MODEL_NAME="$(curl -fsS "http://${POD_IP}:8000/v1/models" | jq -r '.data[0].id')"

curl -fsS "http://${POD_IP}:8000/v1/chat/completions" \
  -H 'Content-Type: application/json' \
  -d "$(jq -n --arg model "${MODEL_NAME}" '{
    model: $model,
    messages: [{role: "user", content: "Reply with exactly: hello from nim"}],
    max_tokens: 16,
    temperature: 0
  }')" | jq -r '.choices[0].message.content'

验证通过后，删除这个非 TEE 示例 Pod 及其 Kubernetes Secret：

kubectl delete pod nvidia-nim-llama-3-1-8b-instruct --ignore-not-found
kubectl delete secret ngc-secret-instruct ngc-api-key-instruct \
  --ignore-not-found

把节点切回机密 GPU 模式：

kubectl label nodes --all nvidia.com/cc.mode=on --overwrite

然后重复上面的 CC 模式稳定性检查，只是这次等待 nvidia.com/cc.mode.state 变成 on。确认节点报告 cc.mode=on 和 cc.mode.state=on 后再继续。

Checkpoint 2：部署 Trustee 并安装 kbs-client

这一节会把 Trustee 直接部署在节点上，后续用于写入 KBS 资源、参考值和资源策略的管理工具 kbs-client。KBS 是 Trustee 暴露给 Guest 侧的证明与资源服务，同时也提供 kbs-client 使用的管理接口。

Trustee 可以通过 Docker Compose、Helm Chart、Kubernetes 清单或其他方式部署。本文选择 Docker Compose，是因为它能直接从 Trustee 源码树同时启动 KBS、Attestation Service（AS）和 Reference Value Provider Service（RVPS）。在这个 Compose 部署中，KBS、AS 和 RVPS 是三个独立容器：KBS 调用 AS 验证证据，AS 再调用 RVPS 获取参考值。Compose 文件里还会有一个一次性运行的 setup 服务，用来生成演示所需的部分密钥材料。

把 Trustee 跑在与工作负载同一台单节点机器上只是为了演示方便，并不代表推荐的生产部署方式。生产环境应把 Trustee 部署在独立的可信环境中，给 KBS 使用持久化存储，使用受信任 CA 签发的 HTTPS 证书，并严格限制管理接口访问。其他部署方式可参考 Trustee installation 文档。

设置 KBS 部署参数

先定义本地工作目录、Guest 组件访问 KBS 时使用的 URL，以及 Compose 部署派生的各个路径。Docker Compose 会把 KBS 端口发布到工作节点主机上。由于这里是单节点集群，Guest 可以直接通过节点 IP 和宿主机端口访问 KBS：

# Local paths.
KBS_WORKDIR="${HOME}/nim-kbs"
KBS_TRUSTEE_DIR="${KBS_WORKDIR}/trustee"
KBS_CONFIG_DIR="${KBS_TRUSTEE_DIR}/kbs/config"
KBS_COMPOSE_CONFIG_DIR="${KBS_CONFIG_DIR}/docker-compose"
KBS_DATA_DIR="${KBS_TRUSTEE_DIR}/kbs/data"
KBS_STORAGE_DIR="${KBS_DATA_DIR}/kbs-storage"

# Artifact selection.
KBS_CLIENT_ARCH="${KBS_CLIENT_ARCH:-x86_64}"

# Network endpoint.
KBS_PORT="${KBS_PORT:-8080}"
KBS_NODE_IP="$(kubectl get nodes \
  -o jsonpath='{.items[0].status.addresses[?(@.type=="InternalIP")].address}')"
KBS_URL="https://${KBS_NODE_IP}:${KBS_PORT}"

mkdir -p "${KBS_WORKDIR}"

这些路径基本都由 KBS_WORKDIR 派生。通常只需要决定 KBS_WORKDIR、KBS_PORT，以及可选的 KBS_CLIENT_ARCH：

• KBS_TRUSTEE_DIR：下载后的 Trustee 源码
• KBS_CONFIG_DIR：Compose 服务挂载使用的演示配置和身份信息目录
• KBS_COMPOSE_CONFIG_DIR：Compose 部署使用的 KBS TOML 配置文件目录
• KBS_DATA_DIR：Compose 管理的演示状态目录，RVPS 参考值和 AS 状态都保存在它的子目录中
• KBS_STORAGE_DIR：KBS 的资源与资源策略仓库存储位置

后面会把 KBS_URL 写进 Pod 的 initdata，供来 Guest 内的 AA 与 CDH 访问 KBS。当前 Compose 方案中，KBS 监听 KBS_PORT 暴露出的宿主机端口，Kata Guest 通过节点 IP 到达该端点。生产环境里，KBS 一般位于独立可信环境，并通过稳定的服务地址暴露；Guest 网络也需要确保能够访问该地址。

生产环境中，建议根据 Trustee 所在信任边界使用合适的持久化存储，例如专用持久卷或可信外部后端。

选择 Trustee 部署制品

这一步要选定 Trustee 源码、Compose 服务镜像，以及与之匹配的 kbs-client 软件制品。原则上，应使用与你当前 CoCo 版本和 Guest 组件匹配、已经验证过的 Trustee 版本。NVIDIA 的 supported-platforms 文档通常是查这个映射关系的权威来源，可参考 NVIDIA supported platforms。

如果你的 Kata 是通过 kata-deploy Helm chart 安装的，通常会在 /opt/kata/versions.yaml 中携带发布元数据。下面的命令会自动读取其中的 coco-trustee 项并解析出匹配的 Trustee 版本。如果这个文件不可用，则需要到对应 Kata 版本的上游 versions.yaml 查找 externals.coco-trustee.version。按当前版本约定，Trustee 的版本号通常比 CoCo 小一个 minor，例如 CoCo v0.18.0 对应 Trustee v0.17.0。如果仍然无法解析，请手工设置 KBS_TRUSTEE_REF。

这种方式很适合本教程，因为相关命令会直接在安装 Kata 的节点上运行。但在生产环境中，应将版本选择纳入部署流程。如果你已经确定要使用的 Trustee 引用，请在运行以下代码片段前设置 KBS_TRUSTEE_REF，这样即可跳过自动查找过程：

KATA_VERSIONS_FILE="${KATA_VERSIONS_FILE:-/opt/kata/versions.yaml}"
KBS_TRUSTEE_REF="${KBS_TRUSTEE_REF:-}"
KBS_IMAGE_REPO="ghcr.io/confidential-containers/staged-images/kbs-grpc-as"
KBS_AS_IMAGE_REPO="ghcr.io/confidential-containers/staged-images/coco-as-grpc"
KBS_RVPS_IMAGE_REPO="ghcr.io/confidential-containers/staged-images/rvps"
KBS_CLIENT_IMAGE_REPO="ghcr.io/confidential-containers/staged-images/kbs-client"

if test -z "${KBS_TRUSTEE_REF}"; then
  if ! test -r "${KATA_VERSIONS_FILE}"; then
    echo "ERROR: cannot resolve KBS_TRUSTEE_REF because ${KATA_VERSIONS_FILE} is not readable." >&2
    echo "Look up the validated Trustee reference for your platform, set KBS_TRUSTEE_REF, and rerun this snippet." >&2
    exit 1
  fi

  KBS_TRUSTEE_REF="$(
    awk '
      $1 == "coco-trustee:" { in_trustee = 1; next }
      in_trustee && $1 == "version:" {
        gsub(/"/, "", $2)
        print $2
        exit
      }
    ' "${KATA_VERSIONS_FILE}"
  )"
fi

if test -z "${KBS_TRUSTEE_REF}"; then
  echo "ERROR: could not find the coco-trustee version in ${KATA_VERSIONS_FILE}." >&2
  echo "Look up the validated Trustee reference for your platform, set KBS_TRUSTEE_REF, and rerun this snippet." >&2
  exit 1
fi

KBS_COMPOSE_IMAGE_TAG="${KBS_COMPOSE_IMAGE_TAG:-${KBS_TRUSTEE_REF}-${KBS_CLIENT_ARCH}}"
KBS_CLIENT_ARTIFACT="${KBS_CLIENT_IMAGE_REPO}:sample_only-${KBS_COMPOSE_IMAGE_TAG}"
KBS_TRUSTEE_TARBALL_URL="${KBS_TRUSTEE_TARBALL_URL:-https://github.com/confidential-containers/trustee/archive/${KBS_TRUSTEE_REF}.tar.gz}"

skopeo inspect "docker://${KBS_IMAGE_REPO}:${KBS_COMPOSE_IMAGE_TAG}" >/dev/null
skopeo inspect "docker://${KBS_AS_IMAGE_REPO}:${KBS_COMPOSE_IMAGE_TAG}" >/dev/null
skopeo inspect "docker://${KBS_RVPS_IMAGE_REPO}:${KBS_COMPOSE_IMAGE_TAG}" >/dev/null
oras manifest fetch "${KBS_CLIENT_ARTIFACT}" >/dev/null

printf 'KBS_TRUSTEE_REF=%s\nKBS_IMAGE=%s:%s\nAS_IMAGE=%s:%s\nRVPS_IMAGE=%s:%s\nKBS_CLIENT_ARTIFACT=%s\nKBS_URL=%s\n' \
  "${KBS_TRUSTEE_REF}" \
  "${KBS_IMAGE_REPO}" \
  "${KBS_COMPOSE_IMAGE_TAG}" \
  "${KBS_AS_IMAGE_REPO}" \
  "${KBS_COMPOSE_IMAGE_TAG}" \
  "${KBS_RVPS_IMAGE_REPO}" \
  "${KBS_COMPOSE_IMAGE_TAG}" \
  "${KBS_CLIENT_ARTIFACT}" \
  "${KBS_URL}"