配置 COW 后端的 Glance 的最佳实践

总结

在 Glance 与 Nova 和/或 Cinder 共享通用存储后端的热门配置中，可能会打开一些已知的攻击向量，从而可能发生恶意数据修改。本说明回顾了已知问题，并建议一种可以缓解此类攻击的 Glance 部署配置。

受影响的服务 / 软件

Glance，所有受支持的发布版本（Queens 到 Zed）

讨论

如果您正在运行将 'show_multiple_locations' 选项设置为 True（默认值为 False）的 glance-api 服务，或者您的面向最终用户的 glance-api 具有将 'show_image_direct_url' 选项设置为 True（默认值为 False）的配置，则本说明适用于您。

我们的建议是，云中的镜像“locations”和“direct_url”字段 [0] *绝不*应向最终用户显示。可以通过运行两个 glance-api 服务来实现这一点

一个“面向用户”的 glance-api，可供最终用户访问，并显示在用户的服务目录中。

一个“仅内部访问”的 glance-api，仅可供需要访问 'direct_url' 或镜像位置字段的服务访问，并受防火墙保护，防止最终用户访问。（Nova、Cinder 和 Ironic 都有配置选项来指定每个服务使用的 Glance API 端点 [1]。）

这种双 glance-api 部署是在 Rocky [2] 到 Ussuri 版本的 Glance 发行说明中的“已知问题”中提出的，但似乎这个想法没有得到足够的重视。因此，本安全说明。

当镜像位置暴露给用户时，可用的攻击向量最初在 OSSN-0065 [3] 中概述，但该说明对攻击面或缓解措施不够清晰，并且包含了一些未实现的展望声明。攻击向量是

[A] 恶意用户可以在 Glance 中创建一个镜像，在该镜像上设置一个指向修改后的镜像的附加位置，然后删除原始位置，以便原始镜像的消费者不知不觉地使用恶意镜像。请注意，但是，此攻击向量无法更改原始镜像的校验和，并且仅限于攻击者拥有的镜像。

OSSN-0065 认为这仅在使用户不校验其镜像数据时才是问题。它忽略了这样一个事实，即在一些流行的部署配置中，Nova 创建根磁盘快照时，数据从不上传到 Glance，而是直接在后端创建快照，并且 Nova 创建一个带有“size” 0 和空“os_hash_value” [4] 的 Glance 镜像记录，从而无法将下载的镜像数据的哈希值与 Glance 维护的值进行比较。

此外，当 Nova 配置为使用与 Glance 镜像存储相同的存储用于临时磁盘时，Nova 会有效地在后端直接创建服务器根磁盘，而无需校验镜像数据。这是为了优化存储空间和主机资源而进行的有意设计选择，但其含义是，即使镜像记录具有记录的哈希值，它也不会在镜像使用时进行检查。

类似地，在使用共享后端或 cinder glance_store 时，Cinder 将有效地从镜像克隆一个卷，直接在后端进行，而无需校验镜像数据。同样，这是为了优化资源而有意完成的，但重要的是要意识到通过此配置所做的安全权衡。换句话说，如果镜像数据在镜像使用时不会被检查，那么就需要格外小心地确保数据路径的完整性。

OSSN-0065 建议可以通过使用策略来解决通过修改镜像位置来替换镜像数据的攻击向量，但事实证明并非如此。目前唯一可以缓解此向量的方法是按照上述描述部署 glance-api，即使用户只能访问的内部 glance-api（已启用 show_multiple_locations），以及面向最终用户的 glance-api（已禁用 show_multiple_locations）。

到目前为止的重点是 'show_multiple_locations'。当 Glance 中禁用该设置时，无法通过 OpenStack Images API 操作位置。但是，请记住，在任何 Glance/Nova/Cinder 配置中，Nova 和/或 Cinder 直接在镜像存储中执行写时复制时，镜像数据传输发生在 Glance 的镜像数据下载路径之外，并且 *不*会检查 os_hash_value。因此，如果后端存储本身受到破坏并且镜像数据直接在后端被替换，则不会检测到替换。

这使我们转向 'show_image_direct_url' 选项，它在 image-show 响应中包含一个“direct_url”字段，可供各种 OpenStack 服务直接从存储后端使用镜像。将 'direct_url' 暴露给最终用户会泄露有关存储后端的信息。具体而言，这些信息是什么取决于所使用的后端及其配置方式，但通常，向恶意行为者提供可能对其尝试通过某种独立漏洞来破坏后端存储有用的提示不是一个好主意。'direct_url' 是只读的，可能看起来无害，但其用途通常是执行某种优化的镜像数据访问，该访问很可能不包括计算镜像数据的哈希值。

因此，我们建议需要暴露 'direct_url' 镜像属性的 OpenStack 服务也配置为使用仅内部访问的 glance-api。值得注意的是，希望下载镜像的最终用户不需要访问 'direct_url' 镜像属性，因为他们可以简单地使用 image-data-download API 调用 [5]。

建议的操作

启用 'show_multiple_locations' 的 glance-api 服务 *绝不*应直接暴露给最终用户。此设置仅应在仅供 OpenStack 服务使用的仅内部访问的 glance-api 上启用，这些服务需要访问镜像位置。例如，可以通过运行具有不同配置文件和使用适当的配置选项为每个服务指定要访问的 Image API 端点的两个 glance-api 服务来实现，并确保特殊内部端点通过防火墙保护，以便只有适当的 OpenStack 服务才能联系它。

同样，启用 'show_image_direct_url' 会暴露有关存储后端的信息，这些信息可能对恶意行为者在尚未知的漏洞中使用有用，因此也应仅在仅内部访问的 glance-api 上启用。

注释 / 参考资料

[0] https://docs.openstack.org/api-ref/image/v2/index.html#show-image-schema

[1] Nova 和 Ironic 在配置文件的 '[glance]' 部分中使用 'endpoint_override'；Cinder 在 '[DEFAULT]' 部分中使用 'glance_api_servers'。

[2] OSSN-0065: https://wiki.openstack.org/wiki/OSSN/OSSN-0065

[3] Glance 的“multihash”元数据对 'os_hash_algo' 和 'os_hash_value' 在 Rocky 中被引入，以取代遗留 md5 'checksum' 字段。python-glanceclient 自版本 2.13.0 起已使用 multihash 校验和进行下载验证。

[4] https://docs.openstack.org/releasenotes/glance/rocky.html#known-issues

[5] https://docs.openstack.org/api-ref/image/v2/index.html?#download-binary-image-data