第 12 章 引导映像的加密密封(技术预览)


为确保从硬件到操作系统的防篡改代码完整性并满足合规性,您可以使用组织 UEFI 安全引导密钥加密密封引导容器映像。这将通过构建、分发和运行时验证整个操作系统映像。

12.1. 了解引导映像的密码密封

您可以使用加密密封为您的 RHEL 引导部署创建从固件到文件系统的端到端完整性链。这可确保您的操作系统仅在根文件系统与构建时签名完全匹配时才启动。

重要

引导映像的加密密封作为技术预览版提供。红帽产品服务级别协议(SLA)不支持技术预览功能,且其功能可能并不完善,因此红帽不建议在生产环境中使用它们。这些预览可让用户早期访问将来的产品功能,让用户在开发过程中测试并提供反馈意见。

您可以通过这些组合组件保护您的映像完整性:

统一内核映像(UKI)
统一内核映像 (UKI) 将内核、initramfs 文件系统 和内核命令行捆绑到一个签名的 EFI 二进制文件中,以防止篡改单个引导组件。与传统的引导链仅验证内核签名不同,UKI 使用相同的签名保护 initramfs 文件系统和命令行。这种体系结构对于密封映像至关重要,因为内核命令行包含Composfs 摘要,这是对系统必须装载的准确文件系统的加密承诺。
Composefs集成

个composefs摘要集成了EROFS、overlayfs和fs-verity来为整个文件系统提供密码验证。构建密封映像时,系统会将操作系统处理成描述每个文件、目录和权限的 EROFS 元数据映像,而不包括实际数据。

相反,它为每个文件条目记录一个fs-verity摘要,而一个单独的内容寻址对象存储则保存了启用内核的fs-verity的实际数据。在装载时,内核使用 overlayfs 将这些组件拼接在一起,而 verity=require 选项则强制内核验证每个服务文件是否与 EROFS 元数据中对应的 fs-verity 摘要匹配。

fs-verity 功能通过计算和存储文件内容的加密哈希树来确保每个文件的完整性。在运行期间,内核在块级验证读取并缓存结果以保持性能。

如果损坏或篡改导致验证失败,内核会立即阻塞数据并返回 I/O 错误 (EIO)。由于这种机制阻止系统为泄密数据提供服务,因此对损坏部分的任何后续读取操作都会失败,即使初始打开调用成功也是如此。

安全启动签名
Secure Boot(UEFI 固件功能)通过维护可信密钥数据库和验证引导加载程序签名,确保在引导过程中仅运行签名的代码。对于密封的映像,它提供了信任的硬件根,保证固件信任后立即执行的软件。
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

关于红帽文档

Legal Notice

Theme

© 2026 Red Hat
返回顶部