
Lennart Poettering 等人发布 Amutable OS 技术概览
来源标题:Amutable Foundations: A Technical Overview
Lennart Poettering、Michael Vogt 和 Joaquim Rocha 公布了 Amutable OS(AOS)的技术概览,这是一个基于镜像的现代 Linux 操作系统。AOS 基于 Fedora 等成熟发行版的软件包,在构建时预组装为不可变磁盘镜像,而非在部署后安装软件包,从而消除配置漂移并提升完整性、鲁棒性和可复现性。配套的 Amutable Control Plane(ACP)用于跟踪、控制、更新和验证 AOS 机群。
以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
作者:Lennart Poettering、Michael Vogt 和 Joaquim Rocha
Amutable OS(“AOS”,或“⊼OS”),一个基于镜像的现代 Linux 操作系统。它构建于成熟 Linux 发行版的基础之上,但将这些发行版从基于软件包的世界带入了基于镜像、完整性受保护的世界。它消除了漂移,并增加了稳健性、完整性和可复现性。一方面,这提供了与企业发行版既往状态之间出色的概念兼容性;另一方面,它从一开始就以基于镜像的 OS 设计为出发点构建。
Amutable Control Plane(“ACP”,或“⊼CP”),一个用于跟踪、控制、更新和验证 AOS 安装集群的管理系统。
Amutable OS 构建于经典 Linux 发行版之上,最初基于 Fedora 软件包。发行版在操作系统的基础组件上做了有价值的集成和统一工作——我们希望利用这些工作。然而,AOS 在构建时使用发行版软件包预先组装不可变磁盘镜像,而发行版传统上则通过在最终部署系统上安装软件包来组合出 Linux 系统。让我们进一步看看这意味着什么。
基于软件包的 OS 通常向用户提供大量定期更新的软件包(数千个),这些软件包具有复杂的依赖关系,并在其最终部署的机器上组合成可工作的 OS。这种风格的安装在不同系统之间往往差异极大。即使为目标系统选择了完全相同的软件包,安装/更新顺序、有状态的更新逻辑以及文件系统数据结构通常也意味着每台机器写入磁盘的字节总是不同的。这被称为漂移。
以这种方式组合的系统因此不可复现、不可预测,并且难以比较和分析——而这对追踪安全问题至关重要。它们也难以测试,因为选择软件包并以任意顺序组装它们的灵活性会导致需要测试的系统组合爆炸,令人望而却步。
基于镜像的 OS 则提供预构建的文件系统镜像,其中包含 OS 所需的所有代码和其他资源。这些镜像在每个部署系统上逐比特完全相同,因此各安装之间仅在运行时获得的本地状态上有所不同,而 OS 代码和资源本身(保持 100% 相同)则没有差异。
为了提高模块化程度,AOS 扩展了这一概念,允许将少量粗粒度镜像合并在一起。每个系统只组合少量镜像(通常少于 5 个),而不是数千个软件包,从而使系统保持可复现。
基于现有发行版软件包构建,使我们能够保证与现有系统具有深远的语义兼容性,同时保持以镜像为核心的方向。特别是,这使我们有可能以很小的代价准备出完全契合客户项目的个性化磁盘镜像。
我已阅读隐私政策* 下一步
模块化
经典发行版软件包是一种模块化概念,在这一点上很有用。在我们的基于镜像的 OS 方法中,我们减少了部署时的模块化,但确实允许一定程度的模块化。这反映了一个事实:虽然我们很可能能够用单个通用、最小的 OS 镜像覆盖大量不同的系统,但某些系统可能需要的部分组件体积庞大或非常特殊,将其拆分出来是合理的。例如,图形/AI 驱动程序和云特定的 agent 服务如今往往体积很大。
为了不必在每个部署主机上都安装它们,我们将某些组件拆分出来,放入系统扩展(简称“sysext”)中;这些扩展包含额外的文件,可以叠加在 /usr/ 中的 OS 资源之上,为系统增加额外资源。将这些组件设为可选,可以减少占用空间和攻击面。
请注意,在许多情况下,在给定主机上激活哪些 sysext 完全取决于该主机的环境和设备。更具体地说,当检测到匹配的硬件时,应自动安装图形驱动程序和子系统。同样,当系统被检测到运行在相关云厂商的环境中时,应自动启用云特定的 agent 服务。
因此在 AOS 中,选择安装哪些额外镜像是某种程度自动化的。本地 AOS 系统带有一个“hwdb”数据库,它规定了当枚举到某些硬件或 VMM 指示某些标识或功能时,应在单个节点上自动安装哪些额外镜像。
AOS 的核心功能之一是支持配置扩展(“confext”)。它们与 sysext 非常相似,但叠加的是 /etc/ 而不是 /usr/。它们被设计为 AOS 上的主要配置管理概念:配置是预先构建好的,并以原子方式应用的镜像形式发送到 AOS 节点;在节点上,配置要么完整出现,要么完全不出现,绝不会只应用一半。换句话说,不仅 AOS 代码,AOS 配置也同样免于漂移并严格可复现。
OS 镜像本身以及 sysext 和 confext 镜像都实现为 UAPI.3 DDI:EROFS 文件系统镜像,结合 Verity 保护数据和加密签名,全部封装在 GPT 分区表作为信封中。对于 confext,这些 DDI 还会额外加密(LUKS)。这意味着不仅在这些组件的下载时,而且在运行期间持续对它们强制实施强完整性保护。对于配置,运行期间还保证机密性。此外,我们不仅保护镜像的内容,还保护文件系统数据结构本身。由于每个镜像都可以通过其 Verity 根哈希进行密码学引用,我们因此获得了一个有用的句柄,可在激活每个镜像之前进行度量(其含义见下文)。
(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。