CNCF 技术监督委员会（TOC）已投票接纳 Confidential Containers 为孵化项目。这次状态变化的重要性不只在于项目成熟度提升，更在于一个长期存在的云安全缺口正在进入云原生基础设施的主航道：数据落盘时可以加密，网络传输时可以使用 TLS，但数据被工作负载实际处理时，如何避免云平台、宿主机或高权限运维人员直接读取？
Confidential Containers 关注的正是“使用中数据”（data in use）保护。它试图让机密计算能力以容器和 Kubernetes 开发者熟悉的方式进入现有工作流，而不是要求每个业务团队重新设计一套虚拟机交付体系。
孵化项目意味着什么
进入 CNCF 孵化阶段，意味着 TOC 已认可该项目的技术方向、治理基础和生态价值。对工程团队而言，这是一个值得进入验证清单的信号，但不应被理解为“所有环境都可以直接投入生产”。
实际采用时仍需确认以下条件：
- 云厂商或本地服务器是否提供受支持的可信执行环境（TEE）。
- Kubernetes 节点、容器运行时和相关底层组件是否匹配。
- 工作负载如何完成远程证明（remote attestation）。
- 镜像、密钥和策略由谁签发、托管与轮换。
- 节点升级、故障迁移、日志采集和调试流程是否仍然可用。
孵化阶段更适合被视为“可以严肃评估和试点”，而不是替代兼容性测试、安全审计与容量验证的认证标签。
它填补的是“使用中数据”缺口
传统云安全通常覆盖两种状态：
- 静态数据：对象存储、数据库文件和磁盘卷通过加密保护。
- 传输中数据：服务间通信通过 TLS 或 mTLS 保护。
然而，应用必须把数据交给 CPU 和内存才能计算。此时，仅有磁盘加密与 TLS 并不能阻止宿主机上的高权限软件观察内存内容。
Confidential Containers 的目标，是把工作负载放入由硬件支持的隔离执行环境，并将这种隔离接入容器编排流程。典型链路可以这样理解：
签名镜像与策略
|
v
Kubernetes Pod -> 机密容器运行时 -> 硬件隔离环境
|
v
远程证明证据
|
v
密钥或敏感配置服务
远程证明在这里非常关键。密钥服务不应因为某个 Pod 声称自己可信就直接释放秘密，而应验证平台和工作负载产生的证明证据，再根据策略决定是否授权。这样，密钥可以只交给满足指定硬件、软件度量值和镜像策略的实例。
在 Kubernetes 中做一个最小试点
下面是一个可改造的最小示例。它假设集群已经安装兼容的机密容器运行时，并且运行时提供名为 kata-cc 的 handler。kata-cc 只是示例名称，执行前必须替换为实际安装文档给出的 handler；普通 Kubernetes 集群直接应用该配置通常会因为缺少对应运行时而失败。
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: confidential
handler: kata-cc
---
apiVersion: v1
kind: Pod
metadata:
name: confidential-demo
labels:
app: confidential-demo
spec:
runtimeClassName: confidential
restartPolicy: Never
containers:
- name: demo
image: busybox:1.36
command:
- sh
- -c
- |
echo "workload started"
uname -a
sleep 3600
将内容保存为 confidential-demo.yaml 后，可以这样创建并检查工作负载：
kubectl apply -f confidential-demo.yaml
kubectl get pod confidential-demo -o wide
kubectl describe pod confidential-demo
kubectl logs confidential-demo
如果 Pod 一直停留在 Pending 或 ContainerCreating，先检查事件与节点运行时配置：
kubectl get events --sort-by=.lastTimestamp
kubectl get runtimeclass confidential -o yaml
kubectl get nodes -o wide
Pod 成功启动只能证明 Kubernetes 找到了相应 RuntimeClass，不能单独证明工作负载已经通过远程证明，也不能证明密钥释放策略有效。一个完整试点还应增加负向测试：修改镜像、策略或预期度量值，确认不受信任的实例确实无法获得秘密。
从演示走向生产要补齐的工程环节
机密容器不是给 Pod 增加一个 runtimeClassName 就完成了安全建设。生产落地至少要覆盖四条链路。
供应链链路需要固定镜像摘要、生成软件物料清单并校验签名。否则，底层执行环境即使可信，也可能只是在可靠地运行一个已被污染的镜像。
证明与密钥链路需要明确证明验证者、策略服务和密钥服务的边界。密钥释放条件应能审计，并避免把长期凭据写入镜像、普通 Secret 或启动参数。
运维链路需要重新评估可观测性。更强的内存隔离往往会限制传统调试方式，因此日志、指标、崩溃转储和应急访问必须提前设计，不能在故障发生后依赖宿主机直接检查进程内存。
性能链路需要使用真实负载测试启动延迟、内存开销、网络与存储吞吐。硬件隔离、额外虚拟化边界和证明流程都可能带来成本，不同平台的结果也不能简单互相套用。
采用建议：先围绕数据边界试点
适合优先试点的工作负载包括跨组织数据分析、敏感模型推理、受监管数据处理，以及不能完全信任基础设施运维面的任务。普通无状态 Web 服务如果不处理敏感数据，可能没有必要承担同样的复杂度和资源成本。
开始试点前，可以用这份清单约束范围：
- 明确威胁模型，写清楚要防范谁，以及不防范什么。
- 选择支持目标 TEE 的节点池，并锁定固件、内核和运行时兼容矩阵。
- 用镜像摘要和证明策略绑定允许执行的工作负载。
- 让密钥释放依赖有效证明，而不是仅依赖 Kubernetes 身份。
- 同时执行允许访问与拒绝访问测试。
- 测量启动时间、吞吐、内存成本和故障恢复时间。
- 为升级、回滚、证书轮换和证明服务不可用准备预案。
Confidential Containers 进入 CNCF 孵化阶段，为云原生机密计算提供了更清晰的协作与治理基础。真正决定项目能否落地的，仍然是硬件能力、证明策略、软件供应链和日常运维能否连成一条可验证的信任链。