层层可信：密封镜像如何将 OS 完整性从启动扩展至运行时

以医院中运行 Linux 的医疗设备为例，它可以处理患者数据、调整给药剂量，并向临床系统发送报告。或者以街角的 ATM 机为例，它能够全天候处理交易。又或者以位于制造网络边缘的网关设备为例，它可以从工厂车间中继转发传感器数据。这些设备上的操作系统（OS）在安装时都经过了验证。但是，每个二进制文件和库是否仍然与构建时完全相同？如果您会对手术室或工厂车间的设备提出这样的保障要求，那为什么不对运行您业务的服务器也抱有同样的期望呢？

启动链中的缺口

通常情况下，默认的通用操作系统安装是“未锁定”的，允许您以 root 身份掌控计算机并进行持久性更改。因此，虽然通用的红帽企业 Linux（RHEL）或 Debian 安装支持安全启动，但通常只有内核是经过签名的。始于固件的加密信任链，并未覆盖根文件系统或应用。但是，对于想要制造“设备”的企业组织来说，可以通过使用自定义签名，将安全启动链式扩展到操作系统的完整性验证，从而提升安全性。

从容器工作流到 OS 完整性

大多数企业组织已通过 CI/CD 管道构建、签名和交付容器镜像。每次拉取容器时，系统都会验证加密摘要。每次启动新容器时，运行时都会确认镜像与签名内容一致。各企业组织早已信任这种模式来保障应用的安全。

RHEL 的镜像模式将相同的容器工作流扩展到操作系统本身。您无需手动或通过脚本来安装和配置 OS，而是在 Containerfile（或其他兼容的 OCI 构建系统）中定义操作系统，将其构建为容器镜像，然后使用 bootc 进行部署。操作系统成为版本化、可再现的工件，并与您的应用通过相同的管道进行流转。更新操作具有原子性，且系统内置回滚功能。每个部署的系统都运行您构建的镜像，并且您可以将该镜像追溯到生成它的构建系统。

在镜像模式的基础上，密封镜像又向前迈进了一步。您构建和签名的操作系统镜像，现在从固件到运行时全程都经过加密验证。您并非在采用一个新流程，而是将您已信任的流程从应用层面扩展到操作系统层面。

工作原理

安全启动和已签名的统一内核镜像已验证启动链：引导加载程序、内核、initramfs。密封镜像则进一步将验证延伸到不可变的 OS 镜像本身，达到文件级精度。使用 composefs 和 fs-verity，可在构建时将 OS 容器镜像的加密摘要直接嵌入到已签名的 UKI 中。在运行时，您或您的团队添加到该镜像的每个文件，都会根据该摘要进行逐一验证。系统拒绝加载任何不匹配的 OS 文件。如果在构建镜像后某些内容被修改、损坏或替换，内核将返回 I/O 错误。系统将不会提供相应文件——不会在记录之后提供，也不会在标记之后提供。它根本无法读取。被篡改的内容实际上已不复存在，因此内核不会将其传递给任何进程。

这对您的基础架构意味着什么

签名链完全由您掌控。您可以生成密钥，对镜像进行签名，并决定系统信任什么。您的监管链中不需要任何供应商参与。

多年来，政府、金融和医疗卫生等行业的高安全性企业组织一直需要这种程度的 OS 完整性。任何有需要的企业组织都可以通过封装镜像实现这一目标。即使您所在的行业不是受严格监管的行业，您也可以确信所用操作系统完全是您自己构建的，并从中获益。

有必要明确说明密封镜像的覆盖范围。该密封机制保护的是不可变 OS 镜像中的文件：基础操作系统，以及您在其上叠加的所有软件。您的监控代理、安全防护工具、应用二进制文件，还有您的团队添加到基础镜像中的特定软件包——这一切都会被密封。它不涵盖 /etc 中的可写配置，也不涵盖 /var 中的运行时状态。这种区分是有意为之。密封机制保护您构建的操作系统。您的配置管理和运行时安全防护工具则帮助保护其余部分。

在本文开头，我提到了医疗设备和 ATM 机，但其应用范围远不止这些示例。想象一下数据中心、边缘机群或制造车间。一个 Containerfile 定义 OS。一条管道负责构建、签名并封装它。同一个密封镜像可部署到裸机、虚拟机或云实例上。无论部署到何处，完整性始终如一。这不是针对少数用例的小众能力，而是操作系统完整性应有的样子。

开始使用

封装镜像在 RHEL 10.2 中以技术预览版形式提供。它基于上游 Linux 技术构建而成，包括 systemd 项目的重要组件、围绕安全启动的现有工具以及 composefs。composefs 提供了一种灵活高效的方式来实现类似于 dm-verity 提供的完整性保障，同时又具备基于文件系统的方案所特有的灵活性。这正是操作系统管理的发展方向。该技术预览版现已开放，相关工具现已可用。未来几周内，我们将在红帽开发人员博客上发布一系列分步指南，帮助您了解以这种方式构建和验证系统在实际操作中的具体情况。