过去几年,云上机密计算主要以“整机加密虚拟机”的形态出现:用户租用一台基于Intel TDX或AMD SEV-SNP的实例,内存与寄存器状态对云厂商不可见。进入2025年,这一形态正在被容器化改写。以CNCF沙箱项目Confidential Containers(CoCo)为代表,机密计算开始以Kubernetes原生工作负载的方式交付,让“默认加密”从少数整机实例扩展到常规微服务。

从整机到容器:交付形态的变化

早期机密计算的门槛在于“整机思维”:要享受内存加密,就得放弃容器化的调度弹性、镜像分层与快速扩缩容,单独维护一批加密实例。对于已经把业务拆成上百个微服务的团队来说,这种代价很难接受,机密计算因此长期停留在密钥托管、跨机构数据协作等少数场景。

CoCo的思路是复用Kata Containers的轻量虚拟机隔离,把每个Pod放进一个由TEE保护的“机密虚拟机”中。对上层而言,它仍然是一个普通的Pod:可以用Deployment声明、可以被HPA扩缩、可以挂载ConfigMap,只是运行时自动叠加了内存加密与远程证明。工作负载无需改造代码,隔离强度却接近整机实例。

硬件与生态的同步推进

容器化之所以能在今年提速,与硬件和编排生态的共同成熟有关。

工程化仍需跨过的三道坎

第一是远程证明链路。容器要拿到解密密钥,必须先向密钥服务证明自己运行在可信硬件上,且镜像摘要、启动参数未被篡改。这条链路涉及证明报告生成、策略校验与密钥释放,任何一环的配置错误都会导致Pod启动失败,排查成本高于普通容器。

第二是性能损耗。内存加密会带来一定的加解密开销,在内存密集型的数据库、缓存类负载上尤为明显;机密虚拟机还需要预留部分内存给安全监控组件。多数团队的做法是先把合规敏感、计算密度适中的服务迁入,而不是一刀切。

第三是运维可见性。传统上云厂商可以通过Hypervisor侧工具做诊断,而机密环境下宿主机无法读取客户内存,可观测性需要下沉到工作负载内部,由用户自己部署采集与日志组件。这对运维体系提出了新的分工要求。

更现实的落地路径

目前较常见的做法是“分层加密”:把持有密钥、处理个人身份信息的服务放入机密容器,把无状态网关、静态资源服务留在普通节点,通过服务网格统一流量与身份。这样既能覆盖主要合规诉求,又避免整体性能与运维成本被拉高。受监管行业的跨机构联合分析、云上密钥与模型权重托管,是当前最活跃的两类场景。

总体来看,机密计算正在从“少数人用得起的整机特性”变为“可按Pod开启的云原生能力”。它不会立刻成为默认选项,但随着证明链路标准化与性能损耗收敛,容器化很可能成为机密计算在云上的主流交付方式。对计划处理敏感数据的团队而言,现在值得做的是梳理数据分级,确认哪些服务真正需要加密内存,再评估引入时机。