蚂蚁宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群

本文主要是介绍蚂蚁宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作者：肖俊贤、闫守孟、秦凯伦

9月25日，在上海外滩大会可信原生技术论坛上，蚂蚁宣布开源 KubeTEE，一个云原生大规模集群化机密计算框架，解决在云原生环境中 TEE 可信执行环境技术特有的从开发、部署到运维整体流程中的相关问题。

KubeTEE 开源地址（或点击“阅读原文”）：

https://github.com/SOFAEnclave/KubeTEE

背景

2018年，蚂蚁集团开始全面转型云原生架构。在落地云原生架构的过程中，蚂蚁集团的工程团队发现，新的技术在带来诸多红利的同时，也带来了很多新的挑战。其中，安全是云原生架构里被忽视的一块短板。经过不断地实践和探索，蚂蚁在2020年提出了“可信原生（Trust-Native）”的理念，将可信任性渗透到云原生架构的各层之中，打造全栈可信赖的云计算基础设施，为业务保驾护航。

机密计算理念，以及可信执行环境 TEE(Trusted Execution Environment) ，作为保护应用的运行安全的技术，也被蚂蚁引入并积极实践，形成了 SOFAEnclave 机密计算技术栈。SOFAEnclave 包括三大组件：

Occlum LibOS：解决业务开发过程中的问题，如传统 TEE 应用开发需要切分重构，依赖 SDK 特定编程语言等问题；
HyperEnclave：解决 TEE 部署环境问题，如硬件 TEE 不普及、软硬件 TEE 使用一致性等问题；
KubeTEE：解决 TEE 集群问题，包括云原生环境特有的从开发、部署到运维整体流程中的相关问题。

2019年云栖大会上，蚂蚁首次介绍了在 SOFAEnclave 机密计算技术栈方面的一些工作。（https://www.sofastack.tech/blog/sofa-enclave-confidential-computing/）一年来，Occlum LibOS 已经开源（https://github.com/occlum/occlum），并捐献给CCC（Confidential Computing Consortium）机密计算联盟。CCC 机密计算联盟隶属于 Linux 基金会，由业界多家科技巨头发起，致力于保护计算数据安全。Occlum 捐献给 CCC，将成为 CCC 社区首个中国发起的开源项目。

本次 KubeTEE 的开源，是业界首个开源的 TEE 大规模集群整体解决方案。蚂蚁将持续拥抱和回馈开源社区，推动行业技术一起向前发展。

KubeTEE 是什么

KubeTEE 是云原生场景下如何使用 TEE 技术的一套整体解决方案，包括多个框架、工具和微服务的集合。就像其名字所暗示的，KubeTEE 结合 Kubernetes 和 TEE 两个重要技术方向，解决可信应用从单点到容器化集群实施过程中的相关问题。

KubeTEE 的目标之一是提供 Serverless 形态的机密计算服务，比如 Trusted FaaS，让业务方只需要实现业务核心逻辑，就可以简单地将之提交到 TEE 环境中运行，而不用重复整套的业务服务开发、部署和运维的流程。

KubeTEE 架构图：

目前，KubeTEE 已经开源的组件包括：

sgx-device-plugin：sgx 容器插件，让容器支持 sgx 特性，由蚂蚁与阿里云团队共同开发；
https://github.com/AliyunContainerService/sgx-device-plugin

trusted-function-framework：TFF 可信应用开发框架，简化可信函数实现过程，屏蔽 SGX 相关细节；
https://github.com/SOFAEnclave/trusted-function-framework

enclave-configuration-service：AECS，基于远程认证的 enclave 配置服务；
https://github.com/SOFAEnclave/enclave-configuration-service

protobuf-sgx：经修改以支持 Enclave 内部使用的 protobuf 协议。
https://github.com/SOFAEnclave/protobuf-sgx

下面来介绍一下如何利用 KubeTEE 的这些组件来开发一个集群化的可信应用。

让可信应用开发变得更简单

目前服务器端 TEE 技术最成熟的代表就是 Intel SGX 技术，目前 KubeTEE 相关工作也都基于 SGX 实现。要让一个基于 SGX 开发的可信应用能够运行起来并持续服务，除了类似一般业务的普通流程以外，还需要一些额外的 SGX 技术相关工作。

在没有 KubeTEE 之前，整个可信应用的开发流程看起来可能像这样：

开发阶段需要做的事情

1. 选择一个合适的开发模式开发可信应用，比如基于 SDK、某种改进的架构、或者 Occlum 这种 LibOS 方式。另外，为了确保软件和平台可信，开发者还需要实现一些类似远程证明和校验的安全相关流程。

2. 需要维护可信代码的签名密钥，访问远程证明服务器的鉴权密钥等。

3. 编译和签名可信应用，如果计划部署到容器环境，还需要制作容器镜像。

部署、运行和维护阶段需要做的事情

1. 获取支持 TEE 特性的机器，并且安装配置 TEE 运行时依赖的相关组件。

2. 确保运行时网络环境正常，比如可以访问远程证明服务器。

3. 合理和高效地调配物理服务器资源，支持 CI、测试和生产等使用需求。

4. 发布和运维可信应用服务，包括扩缩容等。

从完整的软件工程角度看，如果让每个业务开发团队都去重复这些繁琐的工程工作，那无疑是非常低效的。KubeTEE 的目标是通过云原生的手段简化上述过程，帮助业务方更简单、更顺畅地实现基于 TEE 的可信应用和服务，具体包括可信应用开发支持、基础设施支持和微服务辅助支持等方面。

可信应用开发支持

总体来说，KubeTEE 支持如下整个可信应用的开发流程：基于开发框架的应用开发 -> 应用自动化签名服务 -> 基于基础镜像和模板工具的容器打包和上传。

为了满足不同应用场景的开发需求，在 OcclumLibOS 基础上，KubeTEE 开源了 TFF 可信应用开发框架。

其中 Occlum LibOS 主要适用于一些不想修改的旧应用迁移到 TEE 保护，或者一些基于大型框架的不适合切分的应用，或者 C++ 以外其他编程语言开发的应用等。而 TFF 框架主要适用于需要严格控制 Enclave 内部代码性能和安全的轻量应用场景，所以舍弃了对复杂应用的兼容（这部分 Occlum LibOS 可以更好的支持），理念是让 TEE 原生 SDK 支持的分割式编程模型更加稳定和易用。

TFF 利用 protobuf message 简化可信和非可信部分接口函数定义的复杂度、封装远程证明等 TEE 技术底层细节和流程，让使用者只需要关心可信函数的实现和调用逻辑，快速实现可信应用。

因为同样使用了 protobufmessage 来封装数据，所以利用 TFF 框架开发基于 gRPC 的微服务也变得更容易。另外 TFF 还提供容器了基础容器镜像和 dockerfile 文件模板，帮助使用者快速制作一个可信应用容器镜像。

基础设施支持

应用开发就绪之后，需要部署到硬件集群环境中。在基础设施方面，KubeTEE 基于 Kubernetes，利用云原生的方式管理和使用 SGX 物理机器，统一 SGX 主机环境，并抽象成容器逻辑资源池，提供统一的可信应用部署服务，让 TEE 硬件基础设施成为一种可以按需使用的集群化资源。

KubeTEE 开源的 sgx-device-plugin 让业务容器启动时候自动获取 TEE 特性支持，同时方便集群管理和分配 TEE 资源。从工程实践角度，集群中可以隔离 CI、测试、预发和生产环境，满足业务不同阶段对 TEE 基础设施的需求。

微服务辅助支持

业务部署到 TEE 集群中以后，会产生一些远程证明、业务密钥部署和共享、网络代理等通用性需求，还有日志、监控、自愈、扩缩容等运维系统需求。KubeTEE 提供了一些辅助微服务来帮助业务方节省重复开发的人力和时间成本。

其中，KubeTEE 开源的 AECS（Attestation based Enclave ConfigurationService）方案就是为了解决可信应用多个实例间安全共享密钥从而实现无状态服务的问题。AECS 主要提供秘钥生成、导入、存储、管理和分发，远程证明报告代理获取等基础功能，将来可能扩展更多通用配置管理功能，比如证书生成和分发。同时，AECS 支持多种 secret 格式和自定义的 secret 访问 policy，支持多业务之间秘钥隔离管理。