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机密计算技术栈方面的一些工作。一年来，Occlum LibOS已经开源，并捐献给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特性，由蚂蚁与阿里云团队共同开发;
- trusted-function-framework：TFF可信应用开发框架，简化可信函数实现过程，屏蔽SGX相关细节;
- enclave-configuration-service：AECS，基于远程认证的enclave配置服务;
- protobuf-sgx：经修改以支持Enclave内部使用的protobuf协议。
下面来介绍一下如何利用KubeTEE的这些组件来开发一个集群化的可信应用。
让可信应用开发变得更简单
目前服务器端TEE技术最成熟的代表就是Intel SGX技术，目前KubeTEE相关工作也都基于SGX实现。要让一个基于SGX开发的可信应用能够运行起来并持续服务，除了类似一般业务的普通流程以外，还需要一些额外的SGX技术相关工作。
在没有KubeTEE之前，整个可信应用的开发流程看起来可能像这样：
开发阶段需要做的事情
- 选择一个合适的开发模式开发可信应用，比如基于SDK、某种改进的架构、或者Occlum这种LibOS方式。另外，为了确保软件和平台可信，开发者还需要实现一些类似远程证明和校验的安全相关流程。
- 需要维护可信代码的签名密钥，访问远程证明服务器的鉴权密钥等。
- 编译和签名可信应用，如果计划部署到容器环境，还需要制作容器镜像。
部署、运行和维护阶段需要做的事情
- 获取支持TEE特性的机器，并且安装配置TEE运行时依赖的相关组件。
- 确保运行时网络环境正常，比如可以访问远程证明服务器。
- 合理和高效地调配物理服务器资源，支持CI、测试和生产等使用需求。
- 发布和运维可信应用服务，包括扩缩容等。
从完整的软件工程角度看，如果让每个业务开发团队都去重复这些繁琐的工程工作，那无疑是非常低效的。KubeTEE的目标是通过云原生的手段简化上述过程，帮助业务方更简单、更顺畅地实现基于TEE的可信应用和服务，具体包括可信应用开发支持、基础设施支持和微服务辅助支持等方面。
可信应用开发支持
总体来说，KubeTEE支持如下整个可信应用的开发流程： 基于开发框架的应用开发 -> 应用自动化签名服务 -> 基于基础镜像和模板工具的容器打包和上传。
为了满足不同应用场景的开发需求，在Occlum LibOS基础上，KubeTEE开源了TFF可信应用开发框架。
其中Occlum LibOS主要适用于一些不想修改的旧应用迁移到TEE保护，或者一些基于大型框架的不适合切分的应用，或者C++以外其他编程语言开发的应用等。而TFF框架主要适用于需要严格控制Enclave内部代码性能和安全的轻量应用场景，所以舍弃了对复杂应用的兼容(这部分Occlum LibOS可以更好的支持)，理念是让TEE原生SDK支持的分割式编程模型更加稳定和易用。
TFF利用protobuf message简化可信和非可信部分接口函数定义的复杂度、封装远程证明等TEE技术底层细节和流程，让使用者只需要关心可信函数的实现和调用逻辑，快速实现可信应用。
因为同样使用了protobuf message来封装数据，所以利用TFF框架开发基于gRPC的微服务也变得更容易。另外TFF还提供容器了基础容器镜像和dockerfile文件模板，帮助使用者快速制作一个可信应用容器镜像。
基础设施支持
应用开发就绪之后，需要部署到硬件集群环境中。在基础设施方面，KubeTEE基于Kubernetes，利用云原生的方式管理和使用SGX物理机器，统一SGX主机环境，并抽象成容器逻辑资源池，提供统一的可信应用部署服务，让TEE硬件基础设施成为一种可以按需使用的集群化资源。
KubeTEE开源的sgx-device-plugin让业务容器启动时候自动获取TEE特性支持，同时方便集群管理和分配TEE资源。 从工程实践角度，集群中可以隔离CI、测试、预发和生产环境，满足业务不同阶段对TEE基础设施的需求。
微服务辅助支持
业务部署到TEE集群中以后，会产生一些远程证明、业务密钥部署和共享、网络代理等通用性需求，还有日志、监控、自愈、扩缩容等运维系统需求。KubeTEE提供了一些辅助微服务来帮助业务方节省重复开发的人力和时间成本。
其中，KubeTEE开源的AECS(Attestation based Enclave Configuration Service)方案就是为了解决可信应用多个实例间安全共享密钥从而实现无状态服务的问题。 AECS主要提供秘钥生成、导入、存储、管理和分发，远程证明报告代理获取等基础功能，将来可能扩展更多通用配置管理功能，比如证书生成和分发。同时，AECS支持多种secret格式和自定义的secret访问policy，支持多业务之间秘钥隔离管理。
未来展望
目前，KubeTEE已经可以较大程度帮助业务方降低TEE开发复杂度，但是依然任重道远。KubeTEE下一阶段将更多关注云原生场景和机密计算的结合，持续贡献更多组件以及通用服务，让TEE的使用更高效、更简单、更云原生化。
最后，我们衷心希望，KubeTEE能和业界携手，共建更完整的云端安全计算生态。
特别提醒：本网内容转载自其他媒体，目的在于传递更多信息，并不代表本网赞同其观点。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，并请自行核实相关内容。本站不承担此类作品侵权行为的直接责任及连带责任。如若本网有任何内容侵犯您的权益，请及时联系我们，本站将会在24小时内处理完毕。
