快速开始

• 1: 前提条件
• 2: 安装
• 3: 示例工作负载
• 4: 加固工作负载

1 - 前提条件

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

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

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

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:1.22.0
    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 云平台示例