【云原生】机密容器介绍

【云原生】机密容器介绍

1. 数据安全与机密计算

数据在整个生命周期有三种状态：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 中运行的代码。最重要的是，此类证据是由硬件签名，并且制造商能够提供证明，因此验证证据的一方就可以在一定程度上保证证据是可靠的，而不是由恶意软件或其他未经授权的实体生成的。

2. 机密计算的现状与困境

业界内的诸多厂商就已经开始关注并投入到机密计算中。各大芯片厂家和云服务提供商（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，该区域由开发者定义受限的入口和出口函数，有效防止数据泄露。

最近，Intel和Arm推出了新的TEE架构，分别叫做Intel Trust Domain Extensions(TDX) 和 Arm Confidential Compute Architecture(CCA)

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

1、目前提供的技术的使用和开发门槛高。 以开发 Intel® SGX 应用用例，用户需要学习 Intel® SGX 开发技能并对业务进行改造。相比传统开发方式，其使用和开发门槛很高，令很多开发者望而生畏。

2、机密计算容器化和对接 Kubernetes 的成本和复杂度高。 越来越多的用户开始拥抱云原生，即便用户掌握了机密计算的开发技能，让机密计算应用跑在容器里或者跑在 Kubernetes 里还要克服很多问题。比如如何在容器内加载 SGX 驱动，如何为容器合理分配 EPC 内存等。

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

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

3. 机密容器

3.1 Confidential Containers(CC)

Confidential Containers 是一个致力于利用TEE来保护容器和数据以及提供云原生机密计算的开源社区

下图展示了CC的各个组件

从底层开始介绍CC solution（蓝色部分）

• Infra layer - 本地 (bare metal, VMware etc.) 或者公有云上 (AWS, Azure, GCP, etc.)
  • Hardware with CC support - 两个完全不同的模型
    • VM-based TEEs - In this model, memory is encrypted along a traditional VM boundary running on top of a VMM. AMD SEV-SNP, Intel TDX, IBM Secure Execution and Protected Execution Functionality (PEF) are examples of VM-based TEEs.
    • Process-based TEEs - In this model, a process that needs to run securely is divided into two components: trusted and untrusted. The trusted component resides in encrypted memory and handles confidential computing, while the untrusted component interfaces with the operating system and propagates I/O from encrypted memory to the rest of the system. Intel SGX is an example of a process-based TEE.
• Hypervisor - this includes hypervisors such as QEMU/KVM, cloud hypervisor, public cloud provider hypervisors etc…

Confidential Computing services block包含创建一个整体CC平台所需的一系列服务（粉色部分），用户可以使用这些服务来实现他们自己的解决方案，这些服务包括：

• Attestation service - The primary purpose of the attestation service is to validate the evidence provided by the hardware TEE. This is the Verifier, as defined in the RATS architecture.
• Key Broker Service (KBS) - The KBS is the Relying Part, as defined by the ATS architecture. Following are its primary functions:
  • Receive evidence from the Attester (confidential VM or container) via a challenge-response protocol.
  • Relay the evidence to the Attestation Service for verification.
  • Apply appraisal policy for the returned Attestation Results to assess the trustworthiness of the Attester.
  • Interact with the Key Management Service to retrieve the keys and then send them back to the Attester.
• Key management service - A service for securely storing, managing and backing up of cryptographic keys used by applications and users.
• Image build service - Services used to build confidential containers or VM images for end users.
• Image registry - A service that is used to store encrypted and/or signed container and VM images required for CC workloads. Examples of such registries include Quay.io, Docker Hub, CSPs provided registries, etc.

不管是Confidential VM还是Confidential Containers模块都包含Enclave Software Stack，这个stack由负责共同运行整个attestation流程的可信 CC 组件组成，例如：

• 在注入访客所拥有的由依赖方发布的机密后解除对机密 VM 启动进程的阻塞。

• 解密和解压缩受保护的容器映像，并运行其关联的工作负载。

Confidential Container Stack

接下来将描述一个通用架构，用于在VM-based 或者 process-based TEEs上运行k8s pods

虽然这两种方式的具体实现不同，但是它们有着同样的目标和特性：

• Remove cloud and infrastructure providers from the guest application Trusted Computing Base (TCB).
• Integrate natively with the Kubernetes control plane.
• Provide an unmodified Kubernetes user and developer experience.
• Deploy unmodified workloads.

VM-based TEE

下面是用VM-based TEEs部署一个k8s pod的流程：

• CC 负载准备
  • 用户创建容器镜像（例如使用工具podman）
  • 用户签名/加密容器镜像
  • 用户将容器镜像推到镜像仓库中
• 在k8s中部署CC负载
  • 用户部署负载（kubctl apply -f cc_workload.yaml）
  • k8s将负载调度到拥有运行机密容器所需条件的目标host上
• CC负载执行流（红色箭头）
  • host上的机密容器运行时启动VM TEE（The enclave）
  • Enclave（agent）执行远程attestation：图中的1-2步
  • Enclave（agent）获取验证/解密容器镜像所需的keys：图中的3-4步
  • Enclave（image manaement）下载容器镜像：图中的第5步
  • Enclave验证/解密容器镜像：图中的第6步
  • Enclave启动容器负载

process-based TEE

正如所看到的，prcess和VM-based TEEs的工作流基本一样，除了步骤3

• CC 负载准备
  • 用户创建容器镜像（例如使用工具podman）
  • 用户签名/加密容器镜像
  • 用户将容器镜像推到镜像仓库中
• 在k8s中部署CC负载
  • 用户部署负载（kubctl apply -f cc_workload.yaml）
  • k8s将负载调度到拥有运行机密容器所需条件的目标host上
• CC负载执行流（红色箭头）
  • host上的机密容器运行时启动enclave agent
  • Enclave（agent）执行远程attestation：图中的步骤1-2
  • Enclave（agent）获取验证/解密容器镜像的keys：图中的步骤3-4
  • Enclave（image and management）下载容器镜像：图中的第5步
  • Enclave验证解密容器镜像并且写入到本地的加密文件系统中：图中的第6步
  • 运行时启动app enclave，从机密文件系统中读取容器
  • 使用密封或者本地验证来进行agent和app enclaves之间的密钥交换促进了加密文件系统的安全使用

3.2 Inclavare Containers

Inclavare Containers作为业界首个面向机密计算场景的开源容器运行时，为ACK-TEE（ACK-Trusted Execution Environment）提供了使用机密容器的最佳实践。Inclavare Contaienrs 把机密计算技术和容器技术完美结合在一起，其价值可以概括为三点：

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

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

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

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 上到云原生场景中，同时给用户提供更多的技术选择。