Inclavare Containers：云原生机密计算的未来

简介：本文为你详细的梳理一次 Inclavare Containers 项目的发展脉络，解读它的核心思想和创新技术。

作为业界首个面向机密计算场景的开源容器运行时，Inclavare Containers 项目于 2020 年 5 月开源，短短一年多时间内发展势头非常迅猛，吸引了众多领域专家和工程师的关注与贡献。2021 年 9 月 15 日，云原生计算基金会（CNCF）宣布通过全球 TOC 投票接纳 Inclavare Containers 成为 CNCF 官方沙箱项目，成为机密计算技术在云原生领域第一个进入 CNCF 的项目。

不过，如果你对机密计算领域不太关注，可能对 Inclavare Containers 还没有做过太深入的了解。别着急，本文为你详细的梳理一次 Inclavare Containers 项目的发展脉络，解读它的核心思想和创新技术。

首先，什么是 Inclavare Containers？

一言以蔽之，Inclavare Containers 是业界首个面向机密计算场景的开源容器运行时。可是，什么是机密计算呢？Inclavare Containers 跟机密计算又是什么关系？它能帮助我们解决什么问题？

数据安全与机密计算

数据在整个生命周期有三种状态：At-Rest（静态）、In-Transit（传输中）和 In-Use（使用中）。

At-Rest 状态下，一般会把数据存放在硬盘、闪存或其他的存储设备中。保护 At-Rest 状态的数据有很多方法，比如对文件加密后再存放或者对存储设备加密。
In-Transit 是指通过公网或私网把数据从一个地方传输到其他地方，用户可以在传输之前对文件加密或者采用安全的传输协议保证数据在传输中的安全，比如HTTPS、SSL、TLS、FTPS 等。
In-Use 是指正在使用的数据。即便数据在传输过程中是被加密的，但只有把数据解密后才能进行计算和使用。也就意味着，如果数据在使用时没有被保护的话，仍然有数据泄露和被篡改的风险。

在这个世界上，我们不断地存储、使用和共享各种敏感数据：从信用卡数据到病历，从防火墙配置到地理位置数据。保护处于所有状态中的敏感数据比以往任何时候都更为重要。如今被广泛使用的加密技术可以用来提供数据机密性（防止未经授权的访问）和数据完整性（防止或检测未经授权的修改），但目前这些技术主要被用于保护传输中和静止状态的数据，目前对数据的第三个状态“使用中”提供安全防护的技术仍旧属于新的前沿领域。

机密计算指使用基于硬件的可信执行环境（Trusted Execution Environment，TEE）对使用中的数据提供保护。通过使用机密计算，我们现在能够针对“使用中”的数据提供保护。

机密计算的核心功能有：

保护 In-Use 数据的机密性。未经授权的实体（主机上的应用程序、主机操作系统和Hypervisor、系统管理员或对硬件具有物理访问权限的任何其他人。）无法查看在TEE中使用的数据，内存中的数据是被加密的，即便被攻击者窃取到内存数据也不会泄露数据。
保护 In-Use 数据的完整性。防止未经授权的实体篡改正在处理中的数据，度量值保证了数据和代码的完整性，使用中有任何数据或代码的改动都会引起度量值的变化。
可证明性。通常 TEE 可以提供其起源和当前状态的证据或度量值，以便让另一方进行验证，并决定是否信任 TEE 中运行的代码。最重要的是，此类证据是由硬件签名，并且制造商能够提供证明，因此验证证据的一方就可以在一定程度上保证证据是可靠的，而不是由恶意软件或其他未经授权的实体生成的。

机密计算的现状与困境

业界内的诸多厂商就已经开始关注并投入到机密计算中。各大芯片厂家和云服务提供商（Cloud Service Provider，简称 CSP）都在机密计算领域投入研发资源，并组建了“机密计算联盟”。该联盟专门针对云服务及硬件生态，致力于保护计算时的数据安全。

目前支持TEE的硬件平台主要有 3 个：Intel® SGX、ARM TrustZone 和 AMD SEV，他们有不同的应用场景和实现方式。

1、ARM TrustZone 把硬件资源分为安全世界和非安全世界两部分，所有需要保密的操作在安全世界执行，其余操作在非安全世界执行，安全世界和非安全世界通过一个名为 Monitor Mode 的模式进行转换。典型的应用场景有移动支付、数字钱包等。

2、AMD 利用 SEV（AMD Secure Encrypted Virtualizationn），SME（AMD Secure Memory Encryption）和SEV-ES（Secure Encrypted Virtualization-Encrypted State）等技术实现虚拟机的 Guest 内存加密和安全隔离。

3、Intel® SGX 是 Intel 提供的一组指令，用于提高应用的代码和数据的安全性。Intel® SGX 程序由不可信代码和可信 Enclave 组成，敏感的代码和数据放入到 Enclave 中。Intel® SGX 指令在一个特定的加密内存区域（EPC）中创建和执行 Enclave，该区域由开发者定义受限的入口和出口函数，有效防止数据泄露。

目前机密计算目前正处于百花齐发和百家争鸣的阶段，市场和商业化潜力非常巨大。但机密计算在云原生场景中还有一些不足：

1、目前提供的技术的使用和开发门槛高。以开发 Intel® SGX 应用用例，用户需要学习 Intel® SGX 开发技能并对业务进行改造。相比传统开发方式，其使用和开发门槛很高，令很多开发者望而生畏。2、机密计算容器化和对接 Kubernetes 的成本和复杂度高。越来越多的用户开始拥抱云原生，即便用户掌握了机密计算的开发技能，让机密计算应用跑在容器里或者跑在 Kubernetes 里还要克服很多问题。比如如何在容器内加载 SGX 驱动，如何为容器合理分配 EPC 内存等。

3、服务提供商提供的技术方案相对单一。现在很多服务提供商都提供了机密计算的技术方案，但方案总体来说比较单一，并不能完全满足用户上云的需求。比如 Google 的 Asylo 和 Azure 的 OpenEnclave，他们是在 Intel® SGX SDK 的基础上做了封装，以降低用户使用机密计算技术的成本。但这仍然需要用户掌握 Intel® SGX 的开发技能，对用户而言仍然是有学习门槛的。再比如 Occlum、GraphaneSGX 等 LibOS 技术，他们的目的是让用户在不改动代码或做改动很少的代码就能让应用运行在 Enclave中。对用户而言不必再去学习复杂的机密计算的开发技术，但这只是解决了用户开发的问题，但仍然没有解决在容器中运行机密计算应用的问题。

总之，目前已有的机密计算技术方案存在以上困境，不能够完全满足用户不同场景的安全需求。

为了解决以上问题，Inclavare Containers 提供了首个面向机密计算场景的开源容器运行时，把机密计算技术和容器技术完美地结合在一起，其价值可概括为三点：

抹平机密计算的高使用门槛，为用户提供与普通容器一致的使用体感。
基于处理器提供的多种硬件安全技术，提供对多种 Enclave 形态的支持，为用户在安全和成本之间提供更多的选择和灵活性。
加速基于零信任模型的机密计算云基础设施的构建。

Inclavare Containers：云原生机密计算的未来

Inclavare Containers 支持机密应用基于硬件的 TEE 被透明地容器化。带来了以下的好处：

轻松将机密应用带入云原生。
在基于硬件的 TEE 中运行修改/未修改的应用程序（取决于 Enclave Runtime）。
为应用的数据和代码提供机密性、完整性和可证明性。

如下图所示，Inclavare Containers 中包含多个组件，这些组件可以利用基于硬件支持的 Enclave 技术使可信应用运行在容器中。包含的组件有 rune、shim-rune、Enclave Runtime等。

rune：rune 是一个命令行工具，用于根据 OCI 规范在容器中生成和运行 Enclave。rune 是在 runc 代码基础上开发的，既可以运行普通 runc 容器也可以运行 Enclave 容器；rune已经写入 OCI 运行时实现列表：

https://github.com/opencontainers/runtimespec/blob/master/implementations.md。

shim-rune：为容器运行时 rune 提供的 shim，主要负责管理容器的生命周期、把普通镜像转换成 TEE 镜像；管理容器的生命周期，与 rune 配合完成容器的创建、启动、停止、删除等操作。
Enclave Runtime：负责在 Enclave 内加载和运行受信任和受保护的应用程序。rune 和 Enclave Runtime 之间的接口是 Enclave Runtime PAL API，它允许通过定义良好的函数接口来调用 Enclave Runtime。机密计算应用通过这个接口与云原生生态系统进行交互。

一类典型的 Enclave Runtime 实现基于库操作系统。目前，推荐的与 rune 交互的 Enclave Runtime 是 Occlum，这是一种内存安全、多进程 Libos。另一类典型的 Enclave Runtime是带有 Intel® SGX WebAssembly Micro Runtime (WAMR)，这是一个占用空间很小的独立 WebAssembly (WASM) 运行时，包括一个 VM 核心、一个应用程序框架和一个 WASM 应用程序的动态管理。

此外，您可以使用您喜欢的任何编程语言和 SDK（例如英特尔 SGX SDK）编写自己的Enclave Runtime，只要它实现了 Enclave Runtime PAL API。

yun 1.png

Inclavare Contianers主要有以下特点：

1、将 Intel® SGX 技术与成熟的容器生态结合，将用户的敏感应用以 Enclave 容器的形式部署和运行；Inclavare Contianers 的目标是希望能够无缝运行用户制作的普通容器镜像，这将允许用户在制作镜像的过程中，无需了解机密技术所带来的复杂性，并保持与普通容器相同的使用体感。

2、Intel® SGX 技术提供的保护粒度是应用而不是系统，在提供很高的安全防护手段的同时，也带来了一些编程约束，比如在 SGX enclave 中无法执行 syscall 指令；因此我们引入了 LibOS 技术，用于改善上述的软件兼容性问题，避免开发者在向 Intel® SGX Enclave 移植软件的过程中，去做复杂的软件适配工作。然后，虽然各个 LibOS 都在努力提升对系统调用的支持数量，但这终究难以企及原生 Linux 系统的兼容性，并且即使真的达成了这个目标，攻击面过大的缺点又会暴露出来。因此，Inclavare Containers 通过支持 Java 等语言Runtime 的方式，来补全和提升 Enclave 容器的泛用性，而不是将 Enclave 容器的泛用性绑定在“提升对系统调用的支持数量” 这一单一的兼容性维度上；此外，提供对语言 Runtime 的支持，也能将像 Java 这样繁荣的语言生态引入到机密计算的场景中，以丰富机密计算应用的种类和数量。

3、通过定义通用的 Enclave Runtime PAL API 来接入更多类型的 Enclave Runtime，比如 LibOS 就是一种 Enclave Runtime 形态；设计这层 API 的目标是为了繁荣 Enclave Runtime 生态，允许更多的 Enclave Runtime 通过对接 Inclavare Containers 上到云原生场景中，同时给用户提供更多的技术选择。

灵活的机密容器部署方式

Docker 集群

对于普通用户来说，如何运行一个机密容器是一个非常困难的事情，您需要掌握机密计算领域的专业知识，并按照 SGX 应用开发规范开发和构建镜像。而Inclavare Containers 设计并实现了符合 OCI 运行时规范的新型 OCI 运行时 rune，以便与现有的云原生生态系统保持一致，实现了机密容器形态。不仅可以帮您省去这些复杂过程，还可以使您像普通容器一样使用机密容器。

Inclavare Containers 可以与 dockerd 集成。具体来说，您需要在构建容器镜像时安装首选的 Enclave Runtime，并在您的机器的docker 配置文件中添加 rune 的相关配置，例如，/etc/docker/daemon.json。

{"runtimes": {"rune": {"path": "/usr/local/bin/rune","runtimeArgs": []}}
}

然后重启 docker 服务即可。

yun 2.png

由于 rune 是在 runc 代码基础上开发的，所以 rune 既可以创建 runc 容器，也可以创建 Enclave 容器。在 Docker 集群中，创建 runc 容器和创建 Enclave 容器的流程是完全一样的。他们的区别在于镜像。普通 runc 容器镜像是不能创建 Enclave 的，需要用户按照 Enclave Runtime 的要求生成特殊的镜像。如上图所示，使用 docker 启动一个 Occlum 机密容器的的流程如下：

1、用户开发机密应用。用户不需要掌握机密计算的知识，Occlum 提供了工具可以把普通应用转换为机密应用。需要注意的是：Occlum 有一些使用限制，详情请查阅文档：https://github.com/occlum/occlum。

2、基于 Occlum 生成的文件构建镜像，构建成功后推入镜像仓库。3、通过标准 docker 拉起容器镜像，最终使用 rune 运行时启动 Enclave 容器并运行 Occlum 和 Enclave 应用。

Kubernetes 集群

虽然 Docker 集群中能运行 Enclave 容器，但还有一些不足：

无法动态管理和调度 EPC。
容器编排能力弱，没有 Kubernetes 面向终态设计的容器管理方式。

yun 3.png

为此，Inclavare Containers 提供了 shim-rune 用于在云上 Kubernetes 机密计算集群中创建 Enclave 容器。在这种场景下，shim-rune 和 rune 可以组成一个 enclave 容器化栈，所以在构建容器镜像时不需要安装 Enclave Runtime，提供和普通容器一样的体验。

Inclavare Containers 已经添加到 containerd 的采用者列表中：https://github.com/containerd/containerd/blob/master/ADOPTERS.md。此外，shim-rune也支持containerd shim v2 API：https://github.com/containerd/containerd/blob/master/runtime/v2/task/shim.proto。因此，您可以在系统上的 containerd 配置文件（例如 /etc/containerd/config.toml）中添加 shim-rune 的相关配置。

[plugins.cri.containerd]...[plugins.cri.containerd.runtimes.rune]runtime_type = "io.containerd.rune.v2"

然后重启 containerd 即可。

如上图所示，在云上 Kubernetes 机密计算集群中创建 Occlum 机密容器的工作流程如下：

1、kubelet 向containerd 发起 CRI（Container Runtime Interface）请求，比如请求创建一个 Pod。

2、Containerd 中有一个 cri-containerd 的插件实现了 CRI 接口，Containerd 接收到请求后，把请求转给 shim-rune。

3、shim-rune 既可以创建 runc 容器也可以创建 rune 容器。在创建 runc 和 rune 容器的处理流程也有差异：

创建 runc 容器：与创建普通 runc 容器过程完全一样，比如 Pod 的 pause 容器就是 runc 容器。
创建 rune 容器：利用 LibOS 把普通镜像转换成 TEE 镜像，rune 会在容器内创建 Enclave 并把应用运行在 Enclave 中。

4、为每个容器分别创建一个 rune 进程，该进程负责来创建容器，创建 runc 容器和 Enclave 容器的流程是不同的：

创建 runc 容器：与 runc 创建 runc 容器的流程完全一样。
创建 Enclave 容器：每种 Enclave Runtime 都会提供一个实现了 Enclave Runtime PAL API 的动态库so 。rune 先在 Host 上加载 liberpal.so，然后按照 runc 的方式创建容器，并在容器内启动 1 号进程 init-runelet ，init-runelet 接收到 rune 的请求后加载并创建 Enclave。Encalve 包含一般包含两部分：LibOS 和 App/语言 Runtime。LibOS 是 Enclave Runtime 提供的用于支撑应用运行的操作系统库，App/语言 Runtime 是应用本身，有的语言也会有语言 Runtime，比如运行 OpenJDK 11 应用需要 JVM。

5、rune 进程退出，并把 Enclave 容器内 1 号进程的父进程设置为 shim-rune。6、shim-rune 请求 rune 启动 Enclave。至此一个可信应用就运行起来了。

K8s 集群级远程证明架构

为了进一步满足“用户敏感数据的安全性在传输链路上也能够完全不再依赖云厂商”这一安全需求，Inclavare Containers 设计了一套通用的和跨平台的远程证明架构 Enclave Attestation Architecture（简称 EAA）。EAA 以“关联了带有硬件可执行环境的远程证明证据的 TLS 证书”为信任根，确保通信各方的通信信道的安全性完全是基于硬件可信执行环境的。

yun 4.png

EAA的主要组件有：

Enclave-TLS

Enclave-TLS 增强了标准 TLS 以支持基于机密计算技术的异构硬件 TEE 之间的可信通信，是一种支持异构硬件可执行环境的双向传输层安全性协议 (Transport Layer Security，简称TLS）。通过使用 Enclave-TLS，即使是非硬件 TEE 平台也可以通过经过认证的安全信道与硬件 TEE（例如 SGX Enclave）通信以传输敏感信息。总的来说，TCB 的边界从执行环境扩展到使用 Enclave-TLS 的网络传输。此外，Enclave-TLS 有一个可扩展的模型来支持各种硬件 TEE。

机密容器

机密容器扮演证明者的角色。响应来自 Inclavared 的请求，并返回机密容器的attestation evidence（mrenclave 值和 mrsigner 值）。

Inclavared

Inclavared 负责转发下游的机密容器和上游的客户端验证者程序 Shelter 之间的流量，通信过程受到经过证明的 Enclave-TLS 通道的保护。

Shelter

Shelter 作为部署在云下的远程证明验证者，记录 Enclave 运行时的启动度量，然后基于 Enclave-TLS 建立可信信道 Inclavared 进行通信。最后，Shelter 对Enclave 运行时的度量值进行验证，以便租户能够明确知道他们的工作负载是否在真正的 TEE 环境中加载。

具体的工作流程如下：

当用户想验证工作负载是否运行在可信平台上时，可以启动 Shelter 工具发送验证请求给 Inclavared。

1、当接收到 Shelter 的验证请求之后，Inclavared 将请求发送给机密容器，Inclavared 和机密容器分别产生带有 SGX 远程认证信息的 TLS 证书。

2、Inclavared 和 Shelter 之间基于 Enclave-TLS 建立经过证明的安全信道。

3、Inclavared 与机密容器之间基于 Enclave-TLS 建立经过双向认证的安全信道。

4、Inclavared 转发机密容器提供的硬件可执行环境信息和敏感信息给 Shelter

5、Shelter 对 Enclave 运行时的度量值进行验证，并返回验证结果给用户。

五大技术创新

Inclavare Containers 提供了兼容 OCI Runtime 的容器运行时，用户可根据需要在 Docker 集群或者 Kubernetes 集群中运行 Enclave 容器。通过 Enclave Runtime 抹去了用户使用机密计算技术的门槛，在 Kubernetes 集群中更是保持了与普通容器一致的使用体验。通过 Encalve Runtime PAL API 可以提供多种 Runtime 实现，为用户提供更多 Enclave 选择，在安全和成本之间提供更多的选择和灵活性。

Inclavare Containers 的技术创新主要体现在以下几点：

1、实现了标准的应用 enclave 化技术。

将机密计算硬件技术（如Intel® SGX）与成熟的容器生态结合，兼容 OCI Runtime 和 OCI 镜像标准，实现了机密容器形态。用户的敏感应用以机密容器的形式部署和运行，并保持与使用普通容器相同的使用体感。

2、基于Enclave-TLS、shelter、inclavared 设计了灵活可扩展的 K8s 集群级远程证明架构。

通过构建通用且跨平台的远程证明安全架构，能够向用户证明其敏感的工作负载是运行在真实可信的基于硬件的可信执行环境中的。

3、制定了通用的PAL API，规范化了enclave runtime 对接 Inclavare Containers 的接口，打造 Inclavare Containers 的生态。

通过标准的 API 规范来对接各种形态的 Enclave Runtime，在简化特定的Enclave Runtime 对接云原生生态的同时，也为用户提供了更多的技术选择。

4、构造基于零信任模型的机密计算集群基础设施。

移除对云服务提供商的信任，Inclavare Containers 的安全威胁模型假设用户无需信任云服务提供商，即用户工作负载的安全性不再依赖云服务提供商控制的特权组件。

5、与 Kubernetes 生态无缝整合。

Inclavare Containers 可以部署在任何公共云 Kubernetes 平台中，实现了统一的机密容器部署方式。

结语

作为业界首个面向机密计算场景的开源容器运行时，Inclavare Containers 为ACK-TEE（ACK-Trusted Execution Environment）提供了使用机密容器的最佳实践。ACK-TEE 依托 Inclavare Containers，能够无缝地运行用户制作的机密容器镜像，并保持与普通容器相同的使用体感。ACK-TEE 可被广泛应用于各种隐私计算的场景，包括：区块链、安全多方计算、密钥管理、基因计算、金融安全、AI、数据租赁。

未来，Inclavare Containers将继续为开源社区提供面向云原生场景的机密计算容器技术、机密计算集群技术和安全架构，并成为该领域的事实标准。在不断深化实施零信任模型原则的同时，不断提升开发者和用户的使用体验，并最终完全消除与运行普通容器在使用体感上的差别。同时，Inclavare Containers 将积极参与共建云原生社区，深度联手上下游伙伴一同推动云原生安全技术不断进步，为打造更安全的云原生环境不懈努力。

原文链接

本文为阿里云原创内容，未经允许不得转载。