本文发布时间已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
机密 Kubernetes：使用机密虚拟机和 Enclave 提高集群安全性
在这篇博文中，我们将介绍机密计算（CC）的概念，以提高任何计算环境的安全性和隐私属性。此外，我们将展示云原生生态系统，特别是 Kubernetes，如何从新的计算范式中受益。
机密计算是一个之前在云原生世界中引入的概念。机密计算联盟（CCC）是 Linux 基金会的一个项目社区，该社区已经致力于定义和启用机密计算。在白皮书中，他们为使用机密计算提供了很好的动机。
数据存在三种状态：传输中、静止和使用中。……保护所有状态下的敏感数据比以往任何时候都更加重要。密码学现在通常用于提供数据机密性（阻止未经授权的查看）和数据完整性（防止或检测未经授权的更改）。虽然保护传输中和静止状态的数据的技术现在很常用，但第三种状态（保护使用中的数据）是新的前沿。
机密计算旨在通过引入硬件强制的可信执行环境（TEE）来主要解决保护使用中的数据的问题。
可信执行环境
十多年来，可信执行环境（TEE）以硬件安全模块（HSM）和可信平台模块（TPM）的形式在商业计算硬件中可用。这些技术为屏蔽计算提供了可信环境。它们可以存储高度敏感的加密密钥并执行关键的加密操作，例如签名或加密数据。
TPM 针对低成本进行了优化，使其可以集成到主板中并充当系统的物理信任根。为了保持低成本，TPM 的范围有限，即它们仅为少数密钥提供存储，并且仅能够进行一小部分加密操作。
相比之下，HSM 针对高性能进行了优化，为更多密钥提供安全存储，并提供先进的物理攻击检测机制。此外，高端 HSM 可以进行编程，以便可以编译和执行任意代码。缺点是它们非常昂贵。AWS 的托管 CloudHSM 的费用为大约 1.50 美元/小时或 ~13,500 美元/年。
近年来，一种新型的 TEE 越来越受欢迎。诸如 AMD SEV、Intel SGX 和 Intel TDX 等技术提供了与用户空间紧密集成的 TEE。这些 TEE 不是支持特定用例的低功耗或高性能设备，而是可以屏蔽普通进程或虚拟机，并且可以以相对较低的开销执行此操作。这些技术各自具有不同的设计目标、优点和限制，并且它们可在不同的环境中可用，包括消费类笔记本电脑、服务器和移动设备。
此外，我们应该提到 ARM TrustZone，它针对嵌入式设备（如智能手机、平板电脑和智能电视）进行了优化，以及 AWS Nitro Enclaves，它仅在 Amazon Web Services 上可用，并且与 Intel 和 AMD 基于 CPU 的解决方案相比，具有不同的威胁模型。
IBM Secure Execution for Linux 允许你在 IBM Z 系列硬件上的可信执行环境中将 Kubernetes 集群的节点作为 KVM 来宾运行。你可以使用这种硬件增强的虚拟机隔离来为集群中的租户之间提供强大的隔离，并使用硬件证明（虚拟）节点的完整性。
安全属性和功能集
在以下各节中，我们将回顾这些新技术带来的安全属性和其他功能。只有一些解决方案会提供所有属性；我们将在各自的章节中更详细地讨论每项技术。
机密性属性确保信息在 TEE 中使用时无法被查看。这为我们提供了高度期望的功能来保护使用中的数据。根据使用的特定 TEE，代码和数据都可以受到保护，免受外部查看者的侵害。TEE 体系结构以及它们在云原生环境中的使用方式的差异是在设计具有最小可信计算基础（TCB）的敏感工作负载的端到端安全性时的重要考虑因素。CCC 最近致力于通用词汇和支持材料，以帮助解释在不同的 TEE 体系结构中如何绘制机密性边界，以及这如何影响 TCB 的大小。
机密性是一项很棒的功能，但是攻击者仍然可以操纵或注入任意代码和数据供 TEE 执行，从而容易泄露关键信息。完整性向 TEE 所有者保证，在运行关键计算时，代码和数据都不会被篡改。
可用性是在信息安全领域经常讨论的一个基本属性。但是，此属性不在大多数 TEE 的范围之内。通常，它们可以由某些更高级别的抽象（例如 CPU 本身、虚拟机管理程序或内核）来控制（关闭、重新启动等）。这是为了保持整个系统的可用性，而不是 TEE 本身。在云中运行时，可用性通常由云提供商以服务级别协议（SLA）的形式保证，并且不可通过加密强制执行。
机密性和完整性本身仅在某些情况下有用。例如，考虑在远程云中运行的 TEE。你如何知道 TEE 是真实的并且正在运行你预期的软件？它可能是一个冒名顶替者，一旦你发送数据，它就会窃取你的数据。这个根本问题通过可证明性得到解决。证明允许我们根据硬件本身发出的加密证书来验证 TEE 的身份、机密性和完整性。此功能还可以以远程证明的形式提供给机密计算硬件之外的客户端。
可信执行环境 (TEE) 可以保存和处理早于或晚于可信环境的信息。这可能意味着跨重启、不同版本或平台迁移。因此，**可恢复性** 是一项重要功能。在将 TEE 的数据和状态写入持久存储之前，需要对其进行密封，以保持机密性和完整性保证。对这些密封数据的访问需要明确定义。在大多数情况下，解封与 TEE 的身份绑定。因此，要确保恢复只能在相同的机密上下文中进行。
这不一定会限制整个系统的灵活性。 AMD SEV-SNP 的迁移代理 (MA) 允许用户将机密虚拟机迁移到不同的主机系统，同时保持 TEE 的安全属性不变。
功能比较
本文的这些部分将深入探讨具体的实现方式，比较支持的功能并分析其安全属性。
AMD SEV
AMD 的 安全加密虚拟化 (SEV) 技术是一组增强 AMD 服务器 CPU 上虚拟机安全性的功能。SEV 使用唯一的密钥透明地加密每个虚拟机的内存。SEV 还可以计算内存内容的签名，该签名可以发送给虚拟机的所有者，作为证明初始客户机内存未被操纵的证明。
第二代 SEV，称为 加密状态 或 SEV-ES，通过在发生上下文切换时加密所有 CPU 寄存器内容，提供来自虚拟机管理程序的额外保护。
第三代 SEV，安全嵌套分页 或 SEV-SNP，旨在防止基于软件的完整性攻击，并降低与内存完整性受损相关的风险。SEV-SNP 完整性的基本原则是，如果虚拟机可以读取私有（加密）内存页，它必须始终读取它最后写入的值。
此外，通过允许客户机动态获取远程证明声明，SNP 增强了 SEV 的远程证明能力。
AMD SEV 已逐步实现。每个新的 CPU 世代都增加了新功能和改进。Linux 社区将这些功能作为 KVM 虚拟机管理程序以及主机和客户机内核的一部分提供。第一个 SEV 功能在 2016 年进行了讨论和实现 - 请参阅 2016 年 Usenix 安全研讨会的 AMD x86 内存加密技术。最新的重大新增功能是 Linux 5.19 中的 SEV-SNP 客户机支持。
基于 AMD SEV-SNP 的机密虚拟机 自 2022 年 7 月起在 Microsoft Azure 中提供。同样，Google Cloud Platform (GCP) 提供了基于 AMD SEV-ES 的机密虚拟机。
英特尔 SGX
英特尔的 软件保护扩展 (SGX) 自 2015 年起可用，并随 Skylake 架构引入。
SGX 是一组指令集，使用户能够创建一个名为 _enclave_ 的受保护和隔离的进程。它提供了一个反向沙箱，可以保护 enclave 免受操作系统、固件和任何其他特权执行上下文的影响。
无论当前特权级别和 CPU 模式如何，都无法从 enclave 外部读取或写入 enclave 内存。调用 enclave 函数的唯一方法是通过执行多个保护检查的新指令。它的内存已加密。窃听内存或将 DRAM 模块连接到另一个系统只会产生加密的数据。内存加密密钥在每个电源周期随机更改。该密钥存储在 CPU 中，无法访问。
由于 enclave 是进程隔离的，操作系统的库不能按原样使用；因此，需要 SGX enclave SDK 来为 SGX 编译程序。这也意味着应用程序需要进行设计和实现，以考虑受信任/不受信任的隔离边界。另一方面，应用程序使用非常小的 TCB 构建。
一种轻松过渡到基于进程的机密计算并避免构建自定义应用程序的新兴方法是利用库操作系统。这些操作系统有助于在 SGX enclave 内运行本机、未修改的 Linux 应用程序。库操作系统会拦截所有应用程序对主机操作系统的请求，并安全地处理它们，而应用程序并不知道它正在运行 TEE。
第三代 Xeon CPU（又名 Ice Lake 服务器 - “ICX”）及更高版本已切换到使用称为 总内存加密 - 多密钥 (TME-MK) 的技术，该技术使用 AES-XTS，从而不再使用消费者和 Xeon E CPU 使用的 内存加密引擎。这增加了可能的enclave 页面缓存 (EPC) 大小（每个 CPU 高达 512GB），并提高了性能。有关多插槽平台上 SGX 的更多信息，请参阅白皮书。
支持平台的列表可从英特尔获取。
英特尔 TDX
英特尔 SGX 旨在保护单个进程的上下文，而 英特尔的可信域扩展 (TDX) 保护整个虚拟机，因此与 AMD SEV 最为相似。
与 SEV-SNP 一样，对 TDX 的客户机支持也合并到了 Linux 内核 5.19 中。但是，硬件支持将在 2023 年随 Sapphire Rapids 一起推出：阿里云提供了邀请试用实例，而 Azure 已宣布其 TDX 预览机会。
开销分析
机密计算技术通过强大的隔离和增强的安全性为客户数据和工作负载带来的好处并非免费。量化这种影响具有挑战性，并且取决于许多因素：TEE 技术、基准测试、指标以及工作负载类型都会对预期的性能开销产生巨大影响。
基于英特尔 SGX 的 TEE 难以进行基准测试，正如 所示、由、不同论文所证明的那样。选择的 SDK/库操作系统、应用程序本身以及资源要求（尤其是大型内存要求）都会对性能产生巨大影响。如果应用程序非常适合在 enclave 内运行，则可以预期个位数百分比的开销。
基于 AMD SEV-SNP 的机密虚拟机无需更改执行的程序和操作系统，因此更容易进行基准测试。来自 Azure 和 AMD 的基准测试表明，SEV-SNP 虚拟机的开销 <10%，有时甚至低至 2%。
尽管存在性能开销，但它应该足够低，以便真实世界的工作负载可以在这些受保护的环境中运行，并提高我们数据的安全性和隐私性。
机密计算与 FHE、ZKP 和 MPC 的比较
全同态加密 (FHE)、零知识证明/协议 (ZKP) 和多方计算 (MPC) 都是一种加密或密码协议的形式，它们提供与机密计算类似的安全保证，但不需要硬件支持。
全同态加密（也包括部分和某种程度上的）允许对加密数据执行计算，例如加法或乘法。这提供了使用中的加密属性，但不像机密计算那样提供完整性保护或证明。因此，这两种技术可以相互补充。
零知识证明或协议是一种隐私保护技术 (PPT)，它允许一方证明其数据的相关事实，而不会泄露有关该数据的任何其他信息。ZKP 可以代替或与机密计算结合使用，以保护相关方及其数据的隐私。类似地，多方计算使多方能够协同工作进行计算，即，每一方都向结果提供其数据，而不会将其泄露给任何其他方。
机密计算的用例
所提供的机密计算平台表明，单个容器进程的隔离（因此最大限度地减少了可信计算基）和 “完整虚拟机” 的隔离都是可能的。这已经促成了许多有趣且安全的项目的出现
机密容器
机密容器 (CoCo) 是一个 CNCF 沙箱项目，它将 Kubernetes pod 隔离在机密虚拟机内部。
CoCo 可以通过运算符安装在 Kubernetes 集群上。该运算符将创建一组运行时类，这些运行时类可用于在多个不同平台（包括 AMD SEV、英特尔 TDX、用于 IBM Z 的安全执行和英特尔 SGX）上的 enclave 内部署 pod。
CoCo 通常与签名和/或加密的容器映像一起使用，这些映像在 enclave 内部拉取、验证和解密。诸如映像解密密钥之类的机密由可信的密钥代理服务有条件地提供给 enclave，该服务会在释放任何敏感信息之前验证 TEE 的硬件证据。
CoCo 有几种部署模型。由于 Kubernetes 控制平面位于 TCB 之外，因此 CoCo 适用于托管环境。借助在云中启动 pod 虚拟机的 API 适配器，CoCo 可以在不支持嵌套的虚拟环境中运行。CoCo 也可以在裸机上运行，即使在多租户环境中也能提供强大的隔离。
托管的机密 Kubernetes
Azure 和 GCP 都支持使用机密虚拟机作为其托管 Kubernetes 产品的 Worker 节点。
两种服务都旨在通过为容器工作负载启用内存加密来提高工作负载保护和安全保证。然而，它们并不寻求完全隔离集群或工作负载，以防止服务提供商或基础设施的攻击。具体来说，它们不提供专用的机密控制平面，也不公开用于机密集群/节点的证明功能。
Azure 还支持在其托管的 Kubernetes 产品中启用机密容器。它们支持基于 Intel SGX Enclaves 和 基于 AMD SEV 的虚拟机创建机密容器。
Constellation
Constellation 是一个 Kubernetes 引擎，旨在提供尽可能最佳的数据安全性。 Constellation 将您的整个 Kubernetes 集群包裹到一个单一的机密上下文中，该上下文与底层云基础设施隔离。内部的一切始终处于加密状态，包括运行时在内存中。它可以保护 Worker 和控制平面节点。此外，它还与流行的 CNCF 软件（如 Cilium）集成以实现安全网络，并提供扩展的 CSI 驱动程序以安全地写入数据。
Occlum 和 Gramine
Occlum 和 Gramine 是开放源代码库操作系统项目的示例，可用于在 SGX Enclaves 中运行未经修改的应用程序。它们是 CCC 下的成员项目，但公司维护的类似项目和产品也存在。借助这些 libOS 项目，现有的容器化应用程序可以轻松转换为启用机密计算的容器。 许多精选的预构建容器也可用。
我们今天的处境？供应商、局限性和 FOSS 格局
正如我们希望您从前面的章节中看到的，机密计算是一个强大的新概念，可以提高安全性，但我们仍处于（早期）采用阶段。 新产品开始涌现，以利用其独特的属性。
谷歌和微软是首批拥有机密产品的的主要云提供商，这些产品可以在受保护的边界内运行未经修改的应用程序。尽管如此，这些产品仅限于计算，而机密数据库、集群网络和负载均衡器的端到端解决方案必须自行管理。
这些技术为将最敏感的工作负载引入云端提供了机会，并使它们能够利用 CNCF 生态系统中的所有工具。
行动号召
如果您目前正在开发由于法律要求而难以在公共云中运行的高安全性产品，或者您希望将云原生项目的隐私性和安全性提升到一个新的水平：请联系我们重点介绍的所有优秀项目！每个人都渴望提高我们生态系统的安全性，您可以在这个旅程中发挥至关重要的作用。