libvirt驱动程序对flavor和image定义的临时加密的支持

https://blueprints.launchpad.net/nova/+spec/ephemeral-encryption-libvirt

本文档描述了libvirt virt驱动程序的具体实现，以支持Flavor和Image定义的临时存储加密 [1] 规范。

问题描述

libvirt virt驱动程序目前通过LVM imagebackend以及dm-crypt提供的PLAIN加密格式，对临时磁盘加密提供非常有限的支持。

如Flavor和Image定义的临时存储加密 [1] 规范所述，当前实现由计算主机可配置项控制，对最终用户是透明的，不同于通过Cinder的块存储卷加密。

随着Flavor和Image定义的临时存储加密 [1] 规范的引入，我们现在可以实现通过images和flavors加密临时磁盘的支持，从而支持较新的加密格式，例如LUKSv1。 这也具有由QEMU原生支持的优势，正如libvirt驱动程序在附加由Cinder提供的LUKSv1加密卷时所见。

用例

  • 作为基于libvirt的计算云的用户，我希望能够通过选择特定的flavor或image来请求对所有临时存储进行静态加密。

  • 作为基于libvirt的计算云的用户，我希望能够通过选择特定的flavor或image来选择我的临时存储的静态加密方式。

  • 作为用户，我希望附加到我的实例的每个加密临时磁盘都与其关联一个单独的唯一密钥。

  • 作为操作员，我希望允许用户请求使用灵活的LUKSv1加密格式加密其实例的临时存储。

提议的变更

弃用libvirt驱动程序中的遗留实现

libvirt virt驱动程序中使用的遗留实现dm-crypt需要在未来的版本中弃用，包括以下选项

  • [ephemeral_storage_encryption]/enabled

  • [ephemeral_storage_encryption]/cipher

  • [ephemeral_storage_encryption]/key_size

在删除原始实现之前，将使用新的框架引入对dm-crypt的有限支持。

用加密属性填充disk_info

libvirt驱动程序有一个额外的disk_info字典，该字典由前面提到的block_device_info和与实例关联的image metadata的内容构建而成。 随着Flavor和Image定义的临时存储加密 [1] 规范中DriverImageBlockDevice的引入，我们现在可以避免再次查看image metadata，同时还将一些临时加密相关的metadata添加到字典中。

当前该字典包含以下内容

disk_bus

磁盘使用的默认总线

cdrom_bus

光驱使用的默认总线

mapping

一个嵌套字典，以磁盘名称为键，包含有关每个磁盘的信息。

mapping字典中的每个项目包含以下键

bus

此磁盘的总线

dev

libvirt所知的此磁盘的设备名称

type

来自BlockDeviceType枚举的一个类型（‘disk’、‘cdrom’、’floppy’、‘fs’或‘lun’）

它还可以包含以下可选键

format

用于在传递给实例之前格式化swap/临时磁盘（例如‘swap’、‘ext4’）

boot_index

磁盘的基于1的启动索引。

除了上述内容，此规范还将可选地添加以下键，用于加密磁盘

encryption_format

磁盘使用的加密格式

encryption_options

加密选项的字典

encryption_secret_uuid

与磁盘关联的加密密钥的UUID

在imagebackend中处理临时磁盘加密

在上述内容到位后，我们现在可以在每个image backend中添加加密支持。 正如本文档开头所述，此初始支持仅适用于LUKSv1加密格式。

通用的密钥管理代码将引入到基础nova.virt.libvirt.imagebackend.Image类中，并用于在配置的密钥管理器中创建和存储加密密钥。 初始LUKSv1支持将在密钥管理器中为每个磁盘存储密码。 这与当前临时存储加密或加密卷实现不同，后者当前在密钥管理器中存储对称密钥。 由于LUKSv1不直接使用提供的密钥加密数据，因此这仍然是加密卷实现中的一个长期技术债务。

基础nova.virt.libvirt.imagebackend.Image类还将扩展为接受并存储由disk_info（包括格式、选项和secret UUID）提供的可选加密详细信息。

然后将修改每个backend，以便在nova.virt.libvirt.imagebackend.Image.create_image期间使用提供的格式、选项和secret加密磁盘。

启用COMPUTE_EPHEMERAL_ENCRYPTION_LUKS trait

最后，在上述支持到位后，当使用支持LUKSv1的backend时，可以启用COMPUTE_EPHEMERAL_ENCRYPTION和COMPUTE_EPHEMERAL_ENCRYPTION_LUKS trait。 这反过来将启用对任何请求使用该格式的临时存储加密的计算的用户的调度。

备选方案

继续使用透明的主机可配置项，并扩展对其他加密格式（如 LUKS）的支持。

数据模型影响

如上所述，临时加密密钥将添加到libvirt驱动程序中各个磁盘的disk_info中。

REST API 影响

N/A

安全影响

希望这会是积极的，因为每个磁盘和用户可见的选择都使用唯一的密钥来加密临时存储。

通知影响

N/A

其他最终用户影响

用户现在需要通过其image或flavors的选择选择启用临时存储加密，从而选择使用临时存储加密。

性能影响

QEMU将使用libgcrypt库为我们原生解密这些LUKSv1临时磁盘。 虽然过去对此存在性能问题，但可以实现使用dm-crypt代替的解决方法[2]。

其他部署者影响

N/A

开发人员影响

此规范旨在为所有imagebackend实施LUKSv1支持，但将来这些backend支持的任何其他加密格式都需要确保启用匹配的trait。

升级影响

遗留实现已被弃用，但目前仍将继续工作。 由于新实现是独立的，因此没有进一步的升级影响。

实现

负责人

主要负责人

melwitt

其他贡献者

lyarwood

功能联络人

功能联络人

melwitt

工作项

  • 用任何临时加密属性填充disk_info中的各个磁盘字典。

  • 在创建每个磁盘时，将这些属性提供给imagebackend。

  • 在imagebackend中引入基于LUKSv1的加密支持。

  • 当选定的imagebackend支持LUKSv1时，启用COMPUTE_EPHEMERAL_ENCRYPTION_LUKS trait。

依赖项

  • Flavor和Image定义的临时存储加密 [1]

测试

与父规范不同，一旦imagebackend支持LUKSv1并启用所需的trait，我们就可以引入基于Tempest的此实现的测试，以及广泛的功能和单元测试。

文档影响

  • 有关libvirt驱动程序中特定LUKSv1临时加密支持的新用户文档。

  • 有关virt块设备层更改的参考文档。

  • 记录对于raw imagebackend，必须在[libvirt]images_type = raw和[DEFAULT]use_cow_images = False在配置文件中配置，才能使resize工作。 这在没有加密的情况下也是正确的，但对用户来说可能仍然有帮助。

  • 记录用户必须具有在Barbican中创建密钥的策略权限，才能为该用户工作加密。 密钥是使用用户的auth token在Barbican中创建的。 管理员默认具有在Barbican中创建密钥的权限。

参考资料

修订

发布名称

描述

Wallaby

引入

瑜伽

重新提出

Zed

重新提出

2023.1 Antelope

重新提出

2023.2 Bobcat

重新提出

2024.1 Caracal

重新提出