标准化镜像加密和解密¶

OpenStack 已经具备创建加密卷和临时存储的能力，以确保块数据的机密性。尽管目前存储加密镜像也是可行的，但只有 Cinder 服务利用了此选项，并且只能通过 Nova 间接使用（用户必须先从镜像创建卷），因此用户没有直观的方式来创建和上传加密镜像。此外，目前所有用于检测和使用加密镜像的元数据要么不存在，要么仅限于 Cinder 的范围。总而言之，对加密镜像的支持在某种程度上是存在的，但方式不明确且未标准化。为了为所有 OpenStack 服务以及用户建立一致的镜像加密方法，需要在 Glance、Cinder 和 OSC 中进行一些调整。

问题描述¶

上传到 Glance 或通过 Nova 从现有服务器（虚拟机）创建的镜像可能包含敏感信息。已经提供的签名功能仅保护镜像免受篡改。镜像可能存储在多个主机上很长时间。首先，这包括 Glance 自身的镜像存储主机。此外，它可能还涉及计算主机等系统上的缓存。总之，它们暴露于多种潜在场景，涉及不同的主机、不同的访问模式和攻击面。参与这些场景的 OpenStack 组件无法保护镜像数据的机密性。

使用加密存储后端来存储卷和计算主机，并结合从/到加密镜像的直接数据传输，可以实现无需在主机文件系统上暴露镜像数据的流程。将加密密钥存储在专用的密钥管理主机上，也能确保密钥的隔离和访问控制。

如上文介绍所述，Nova 中临时磁盘和 Cinder 中卷的一些磁盘镜像加密实现已经涉及到了这个主题，但并非总是以标准化和可互操作的方式进行。例如，处理镜像元数据和加密密钥的方式可能不同。此外，用户在提供自己的镜像时，很难使用这些实现，从而使加密在所有服务中以相同的方式工作。

因此，我们建议引入一种简化的加密镜像格式，以及将在 OpenStack 服务中支持现有加密实现并提高互操作性和用户可用性的明确定义的元数据规范。

用例¶

1. 用户希望基于加密镜像创建新的卷。相应的卷主机必须能够检测到镜像已加密。此外，加密镜像应始终生成加密卷，以避免解密。

1 如果加密镜像作为新卷的基础，则使用的卷类型应始终具有加密类型。 如果给定的卷类型或默认卷类型没有加密类型，则操作应导致错误。

2 加密镜像有两种可能的类型：qcow2 和 raw 镜像。 Cinder 已经可以处理加密的 raw 镜像。 加密的 qcow2 镜像可能需要在传输到卷之前先展平为 raw 格式。

3 从加密卷创建的加密镜像，可能会根据 Cinder 的 allow_compression_on_image_upload 选项进行压缩。 在从此类镜像创建加密卷时，也需要处理此问题。

2. 每当加密镜像转换为加密卷时，都应复制密钥，以便 Cinder 完全控制密钥的生命周期。

2.1 密钥可以是密钥或密码短语。密钥管理器中的密钥类型分类将确定密钥处理方式（“对称”与“密码短语”）。目前，Cinder 只能处理“对称”密钥。需要添加对“密码短语”的支持（如 Nova 中使用的）。

3. 用户希望从具有加密卷类型的卷创建镜像。目标镜像将重用 LUKS 加密和密钥。此用例已经作为 Cinder 的默认行为实现。

1 从未加密的卷创建加密镜像将不在本规范的范围内，但以后可能会实现。

2 从加密卷创建未加密的镜像目前是不可能的。 卷加密也透明地用于镜像。 此行为将保持不变，以优化资源使用并避免在卷主机上进行整个卷数据的代价高昂的转换。

提议的变更¶

在 Glance 中，我们建议以下附加元数据属性应由加密镜像携带

‘os_encrypt_format’ - 使用的主要机制，例如 ‘LUKS’
‘os_encrypt_cipher’ - 密码算法，例如 ‘AES256’
‘os_encrypt_key_id’ - 密钥管理中的密钥引用
‘os_encrypt_key_deletion_policy’ - 镜像删除时，指示是否应删除密钥
‘os_decrypt_container_format’ - 格式更改，例如从 ‘compressed’ 到 ‘bare’
‘os_decrypt_size’ - 负载解密后的尺寸

我们建议与 Nova 和 Cinder 对齐，并使用 LUKS，LUKS 将允许与 qcow 和 raw 镜像结合使用。我们使用这两个版本的原因如下

Nova 可以直接使用 qcow-LUKS 加密来创建服务器。这是 Nova 的标准流程。
Cinder 允许从加密卷创建镜像。这些将始终生成 LUKS 加密的 raw 镜像。这些镜像可以直接转换回卷。

在后一种情况下，已经可以将这样的加密镜像上传到另一个 OpenStack 基础设施，上传密钥并设置相应的元数据。完成后，可以在第二个基础设施中使用该镜像来创建加密卷。

我们希望通过标准化使用的元数据参数并尽可能添加互操作性来对齐 Nova 和 Cinder 之间的现有实现。对于 Cinder 而言，这主要是重命名：- ‘cinder_encryption_key_deletion_policy’ 到 ‘os_encrypt_key_deletion_policy’ - ‘cinder_encryption_key_id’ 到 ‘os_encrypt_key_id’

在卷创建过程中，将添加一个检查，以查找作为卷源提出的加密镜像。如果镜像已加密，则添加另一个检查以确定创建卷的卷类型是否具有加密类型。如果不是，则卷创建将在 API 中中止。否则，将创建一个无法使用的卷。

qcow2 镜像的展平应在将镜像上传到卷时处理。卷大小应由 ‘os_decrypt_size’ 参数确定。如果通过 Cinder 的 allow_compression_on_image_upload 选项启用了压缩，则应重用 Cinder 的实现来处理此问题。

从加密镜像创建加密卷的密钥管理必须包括将密钥复制到 Barbican。这样，Cinder 始终可以完全控制密钥的生命周期，因为这种方式与原始加密卷的创建方式类似。

在 Cinder 中使用的所有解密位置，都需要进行额外的检查，以确定密钥的类型。如果密钥是“密码短语”，则需要进行不同的处理，因为 Cinder 处理密钥以创建 LUKS 标头的密码短语的方式非常独特，并且与 Nova 处理仅具有密码短语的镜像的方式不同。

从卷创建镜像只需要调整为使用新参数即可。

备选方案¶

我们还评估了基于 GPG 的镜像加密实现。这种实现的一个缺点是，每次使用这样的镜像来创建服务器或卷时，都必须解密该镜像，并可能为了另一种加密格式而重新加密，因为 Nova 和 Cinder 都使用 LUKS 作为加密机制。这不仅会影响操作的性能，还需要为加密镜像文件、解密部分以及创建的加密卷或服务器提供可用空间。

数据模型影响¶

无

REST API 影响¶

在从加密镜像创建卷时，可能会触发一个新的错误，即如果镜像已加密但未提供加密卷类型时。

安全影响¶

对 OpenStack 的安全性有影响

本规范将解决镜像中数据机密性的问题
正式引入镜像加密，因此加密算法将在所有相关组件（Nova、Cinder、OSC）中使用

Active/Active HA 影响¶

无

通知影响¶

无

其他最终用户影响¶

用户应能够以一致的方式使用加密镜像来创建卷

性能影响¶

Cinder API 的建议检查可能会对性能产生微小影响。

从加密镜像创建卷或服务器时，可能触发的唯一操作是 qcow-LUKS 和 raw LUKS 块之间的转换。

因此，任何性能影响仅适用于新引入的加密镜像类型，其中镜像处理将比常规镜像具有更高的计算成本和更长的处理时间。影响将因各个主机性能和支持的密码算法 CPU 扩展而异。

其他部署者影响¶

为了 OpenStack 服务之间的互操作性，密钥管理器的存在应决定是否可以使用加密。
如果使用加密镜像，则需要密钥管理器 - 例如 Barbican。

开发人员影响¶

无

实现¶

负责人¶

主要负责人：Markus Hentsch (IRC: mhen)

其他贡献者：Josephine Seifert (IRC: Luzi)

工作项¶

在创建卷 API 中添加检查
添加将密钥复制到 Barbican 并注册为消费者
添加 qcow2 到 raw 加密镜像的展平
在从卷创建镜像时：将 ‘cinder_encryption_key_deletion_policy’ 更改为 ‘os_encrypt_key_deletion_policy’，将 ‘cinder_encryption_key_id’ 更改为 ‘os_encrypt_key_id’

依赖项¶

必须实现 Glance 中镜像加密参数的存在

测试¶

Tempest 测试需要访问加密镜像才能进行测试。这意味着 Tempest 需要提供一个已经加密的镜像文件及其相应的密钥，或者能够自行加密镜像。这一点仍在讨论中。

文档影响¶

应记录部署者如何启用 OpenStack 配置中的此功能。

参考资料¶

[1] Barbican Secret Consumer Spec: https://review.opendev.org/#/c/662013/

[2] Glance Image Encryption Spec: https://review.opendev.org/c/openstack/glance-specs/+/915726

历史¶

修订版¶
发布名称	描述
Dalmatian	引入

标准化镜像加密和解密