风味和镜像定义的临时存储加密¶
https://blueprints.launchpad.net/nova/+spec/ephemeral-storage-encryption
本规范概述了 Nova 中临时存储加密的一种新方法，允许用户通过使用具有特定额外规格的风味或具有特定属性的镜像来选择其临时存储在静态时的加密方式。目标是将 Nova 中的临时存储加密体验与 Cinder 提供的块存储加密实现保持一致，在 Cinder 中可用的用户可选择的加密卷类型。
注意
本规范仅涵盖 API 和计算层的高层更改，特定虚拟驱动程序中的实现留待单独的规范说明。
问题描述¶
目前，仅 libvirt 虚拟驱动程序在使用 lvm imagebackend 时提供内置的临时存储加密支持。当前的实现为基础操作员提供主机特定的临时磁盘静态加密支持，所有给定计算节点上的实例都强制使用 dm-crypt PLAIN 加密格式进行加密。
这并非理想状态，并且使临时存储加密对最终用户完全不透明，与 Cinder 提供的块存储加密支持相反，在 Cinder 中，用户能够选择使用管理员定义的加密卷类型来确保其存储在静态时被加密。
此外，当前的实现使用单个对称密钥来加密与实例关联的所有临时存储。由于使用了 PLAIN 加密格式，因此无法就地轮换此密钥。
用例¶
作为用户，我希望通过选择特定的风味或镜像来请求加密我所有的临时存储在静态时。
作为用户，我希望通过选择特定的风味或镜像来选择如何加密我的临时存储在静态时。
作为管理员/操作员，我希望能够强制对风味或镜像进行临时加密。
作为管理员/操作员，我希望为我的最终用户提供有关如何加密其临时存储在静态时的合理选择。
作为虚拟驱动程序维护者/开发人员，我希望表明我的驱动程序支持使用特定加密格式的临时存储加密。
作为虚拟驱动程序维护者/开发人员，我希望为希望加密其临时存储在静态时的用户提供合理的默认加密格式和选项。我希望这些与加密存储相关联，直到它被删除为止。
提议的变更¶
为了启用此功能，将引入新的风味额外规格、镜像属性和主机可配置项。这些将控制何时以及如何为实例启用临时存储静态加密。
注意
以下 hw_ephemeral_encryption 镜像属性与镜像在 Glance 服务中是否加密在静态时无关。它们仅与使用 Nova 中配置的实例的临时存储将如何加密在静态时有关。
允许通过风味、镜像或配置来配置临时加密¶
为了启用每个实例的临时加密，将引入以下基于布尔值的风味额外规格和镜像属性
hw:ephemeral_encryptionhw_ephemeral_encryption
以上将启用实例的临时存储加密，但不会控制所使用的加密格式。为此，将使用配置选项来为每个计算节点提供默认格式，该格式最初默认为 luks，目前没有其他选择。
[ephemeral_storage_encryption]/default_format
为了启用使用临时加密的实例的快照和搁置，加密密钥的 UUID 和结果镜像的加密格式将使用标准化的 Glance 镜像属性 [1] 与镜像一起保存。
os_encrypt_key_idos_encrypt_format
在从临时加密快照创建实例或取消搁置临时加密实例时，需要加密密钥 UUID 和加密格式。
其他 os_encrypt* Glance 镜像属性也会在快照时设置
os_encrypt_cipher- 密码算法，例如 ‘AES256’os_encrypt_key_deletion_policy- 在镜像删除时指示是否应删除密钥os_decrypt_container_format- 格式更改，例如从 ‘compressed’ 到 ‘bare’os_decrypt_size- 解密有效负载后的尺寸
可能的未来工作¶
在未来，我们可以考虑支持一个混合了提供 LUKSv1 (qcow2|raw|rbd) 或传统 dm-crypt PLAIN (LVM) 加密格式的计算主机的云。
所使用的加密格式将由以下风味额外规格和镜像属性控制
hw:ephemeral_encryption_formathw_ephemeral_encryption_format
并用于调度到支持指定格式的计算主机。
该格式将作为字符串提供，该字符串映射到 BlockDeviceEncryptionFormatTypeField oslo.versionedobjects 字段值
legacy_dmcrypt_plain用于 dm-crypt PLAIN 格式luks用于 LUKSv1 格式
如果两者均未指定，则格式将从 os_encrypt_format [1] 获取，如果源镜像已加密。如果源镜像未加密，则格式将从 [ephemeral_storage_encryption]/default_format 获取，实例降落在计算主机上之后。
使用密钥管理器服务的密钥数据管理¶
加密磁盘的密码由密钥管理器服务（例如 Barbican）管理。
Nova 将使用调用 Nova API 的用户的授权令牌来创建、检索和删除磁盘密码。云操作员必须考虑与服务器操作以及允许谁执行服务器操作相关的密钥所有权影响
┌─────────────────────┐ ┌────────────────────┐
│ │ │ │
│ │ │ │
│ Nova API │◄───────────────────────┤ Barbican API │
│ │ │ │
│ ├─────┬────────────┬────►│ │
│ │ │ User token │ │ │
│ │ └────────────┘ │ │
│ │ │ │
└──────────▲──────────┘ └────────────────────┘
│
│
│
│
│
┌────────────┤
│ User token │
└────────────┤
│
│
│
│
┌─────────┐
│ │
│ User │
│ │
└─────────┘
默认情况下，Barbican 将密钥的所有权限定为项目级别。这意味着 Barbican API 中的许多调用将执行额外的检查，以确保令牌的 project_id 与存储为密钥所有者的 project_id 匹配。在此配置中，同一项目的成员可以访问彼此的密钥。
对于仅限管理员的 API，例如冷迁移、实时迁移和撤离，调用 Nova API 执行这些服务器操作的用户需要
访问服务器所有者的 Barbican 密钥
为了调用仅限管理员的 Nova API，例如冷迁移、实时迁移、撤离等，需要
admin角色
在默认的 Barbican 配置中，密钥所有权将限定为创建它的项目，因此在这种环境中，用户需要成为 项目管理员或同时具有项目成员资格和 admin 角色的任何用户。
请注意，云操作员可以使用 访问控制列表在 Barbican 中实施更细粒度的密钥控制。例如，密钥可以限定为用户级别，而不是项目级别。在这种配置中，项目管理员将不允许对项目中属于不同用户的服务器执行仅限管理员的 API 服务器操作。
操作员必须提前计划，以确定他们在环境中需要的 Barbican 密钥配置和访问控制。
重要
对于使用 [oslo_policy]enforce_scope = False 在其服务配置文件中进行的传统部署，需要额外步骤才能允许用户创建具有加密本地磁盘的服务器。
在传统部署中，用户必须在 Keystone 中分配给他们 creator 角色或 admin 角色，才能允许他们在 Barbican 密钥管理器服务中创建密钥。否则，用户请求创建具有加密本地磁盘的服务器将失败。
$ openstack role list
+----------------------------------+---------------------------+
| ID | Name |
+----------------------------------+---------------------------+
| 068b4910f0eb4a1cb6a4a2a1e94c3dfe | reader |
| 25dc4ed8f3814fd1941a580d78f2b635 | service |
| 7e832eeb2c2842c9b03c376bf3113247 | creator |
| 59df386beb0f460095b7622fc1a45e22 | member |
| 655bbf1b9f844399bcfbfbbef4248045 | admin |
+----------------------------------+---------------------------+
为每个块设备映射创建一个新的密钥管理器密钥¶
磁盘镜像密钥的方法是每个磁盘镜像都有一个唯一的密钥。
例如
假设 Instance A 有 3 个磁盘：一个根磁盘、一个临时磁盘和一个交换磁盘。每个磁盘都有自己的密钥。
对于 qcow2，如果从加密源镜像创建实例，则生成的 backing 文件将与源镜像具有相同的密码，以便 backing 文件可以在多个实例之间共享。对于共享 backing 文件的每个实例，实例都有密钥的“副本”（一个新的 Barbican 密钥，该密钥具有相同的密码）。
这可以防止 Barbican 密钥删除的单点故障。例如，如果 100 个实例共享相同的加密 backing 文件，并且用户错误地删除了 backing 文件的 Barbican 密钥，则只会受到一个实例或镜像的影响。如果一个 Barbican 密钥由使用相同加密 backing 文件的 100 个实例共享，则 100 个实例和源镜像都会受到影响。
Barbican 具有用于密钥消费者的参考计数 API，该 API 会通过 HTTP 递增和递减内部计数器。如果由于任何原因给定密钥的计数不正确变为零，则随着时间的推移，（竞争条件等），API 将允许删除该密钥，即使它正在使用中。
此表旨在说明在各种情况下处理密钥的方式。
实例或镜像 |
磁盘 |
密钥（密码） |
注意事项 |
|---|---|---|---|
Instance A |
disk (root) |
Secret 1 |
Secret 1、2 和 3 将在删除 Instance A 及其磁盘时由 Nova 自动删除 |
disk.eph0 |
Secret 2 |
||
disk.swap |
Secret 3 |
||
从 Instance A 创建的 Image Z (快照) |
disk (root) |
Secret 4 (默认情况下是 Secret 1 的副本) |
Secret 4 将不会自动删除，并且在从 Glance 删除 Image Z 时需要手动删除 |
从 Image Z (快照) 创建的 Instance B |
disk (root) |
Secret 5 * (Secret 4 的副本) |
Secret 5、6、7 和 8 将在删除 Instance B 及其磁盘时由 Nova 自动删除 |
Secret 6 |
|||
disk.eph0 |
Secret 7 |
||
disk.swap |
Secret 8 |
||
Instance C |
disk (root) |
Secret 9 |
Secret 9、10 和 11 将在删除 Instance C 及其磁盘时由 Nova 自动删除 |
disk.eph0 |
Secret 10 |
||
disk.swap |
Secret 11 |
||
由 Instance C 的搁置创建的 Image Y (快照) |
disk (root) |
Secret 9 |
Secret 9 在 Instance C 被搁置时被重用，部分原因是为了防止根磁盘密钥的所有权发生变化，例如，如果管理员用户搁置非管理员用户的实例。 |
由 Instance A 的救援创建的救援磁盘 |
disk (root) |
无 |
只有指定加密救援镜像时，救援磁盘才会被加密。 |
使用加密救援镜像救援 Instance A |
disk (root) |
加密救援镜像的密钥 |
加密救援镜像的密钥将被重用，不会创建或删除新密钥 |
* qcow2 的 backing 文件密钥
加密源镜像¶
创建自加密源镜像的实例的默认行为是创建加密磁盘。原因是我们的目标是避免镜像“意外”解密，并且解密应该由用户、flavor 或镜像选择加入并明确请求，以便清楚地表达意图。
加密的源镜像将在其镜像元数据中拥有 os_encrypt_key_id、os_encrypt_format 以及其他 [1] 镜像属性。
目前，我们预计将使用一组标准化的镜像属性
os_encrypt_format- 用于了解如何解释镜像格式
os_encrypt_key_id- 如果需要，用于复制/转换/等源镜像
当从加密源镜像创建带有加密磁盘的实例时，如果未设置 hw_ephemeral_encryption，我们将使用自动存储的 image_os_encrypt_key_id 系统元数据，或者可能在实例系统元数据中存储 image_hw_ephemeral_encryption=true，并使用它来确保实例将被调度到支持临时加密的计算主机。
如果加密镜像上设置了 os_encrypt_key_id 镜像属性，并且镜像或 flavor 也显式设置了 hw_ephemeral_encryption=false 或 hw:ephemeral_encryption=false，那么目前我们将以 409 冲突错误拒绝 API 请求。
我们可以考虑未来的工作来解释上述镜像属性设置的组合，将其解释为有意请求从加密源镜像创建未加密磁盘的实例，并执行解密操作。
加密的 backing 文件 (qcow2)¶
关于 backing 文件的处理方式是，如果创建它的源镜像已加密，则 backing 文件将被加密。如果创建磁盘的源镜像未加密，那么 Nova 内部存储的 backing 文件也不会被加密。如果源镜像已加密，则 backing 文件也将被加密。
加密的 backing 文件使用与创建它的源镜像相同的密码短语。这对于在同一项目中的多个实例之间共享加密的 backing 文件是必需的。
临时磁盘和交换磁盘的 backing 文件永远不会被加密，因为它们始终从空白磁盘创建。
带有临时加密的实例的快照¶
当带有临时加密的实例被快照时，加密镜像快照的行为将由添加到快照 API 的请求参数决定。
API 请求参数旨在支持涉及与其他项目或用户共享加密镜像快照的工作流程。
示例
实例所有者想要备份他们的磁盘
实例所有者想要创建一份使用新密钥加密的磁盘副本
实例所有者想要创建一份使用属于不同项目或用户的现有密钥的磁盘副本（前提是该项目或用户已为该密钥创建必要的 访问控制列表）
实例所有者想要创建一份未加密的公共磁盘副本
拥有未加密磁盘的实例所有者想要创建一个加密的副本，以促进其磁盘到另一个位置的安全外泄
Create Image (createImage Action) API 的新 API 微版本¶
将向 create image API 添加一个新的微版本，以支持临时加密选项。用户可以选择他们希望如何处理新镜像快照的加密。他们可以使用与被快照的镜像相同的密钥（默认），让 Nova 生成一个新密钥并使用它来加密镜像快照，提供他们自己的密钥 secret UUID 来加密镜像快照，或者根本不加密镜像快照。
对 POST /servers/{server_id}/action 的请求，带有 createImage¶
名称 |
In |
类型 |
描述 |
|---|---|---|---|
server_id |
path |
string |
服务器的 UUID。 |
createImage |
body |
对象 |
创建镜像或服务器卷快照的操作。 |
name |
body |
string |
镜像的显示名称。 |
metadata (可选) |
body |
对象 |
镜像的元数据键值对。每个元数据键和值的最大大小为 255 字节。 |
encryption (可选) |
body |
对象 |
要创建的镜像的加密选项。这些选项仅适用于加密的本地磁盘。 |
encryption.key |
body |
string |
用于加密镜像快照的密钥。有效值为
|
encryption.secret_uuid (可选) |
body |
string |
用于加密镜像快照的密钥管理器服务 secret 的 UUID。 |
{
"createImage" : {
"name" : "foo-image",
"metadata": {
"meta_var": "meta_val"
},
"encryption": {
"key": "same|new|existing|none",
"secret_uuid": "<secret uuid> if 'key' is 'existing', or absent"
}
}
}
encryption.key 的请求选项
same使用相同的密钥来加密新的磁盘镜像。这是默认值。
new生成一个新密钥来加密新的磁盘镜像。
existing使用提供的
<secret uuid>来加密新的磁盘镜像。无不加密新的磁盘镜像。
注意
Ceph Quincy (v17) 及更早版本不支持使用与父镜像不同的加密密钥创建克隆镜像。因此，对于 Ceph 的这些版本，encryption.key 请求参数的值为 new 不会受 rbd 镜像后端支持。
如果用户请求使用 encryption.key 和 new 的快照，并且 Ceph <= Quincy (v17)，则快照服务器操作将被标记为失败，并显示一条消息，解释 new 在部署中不受支持。
对 POST /servers/{server_id}/action 的请求，带有 createImage¶
(响应参数不会有任何更改。)
名称 |
In |
类型 |
描述 |
|---|---|---|---|
image_id |
body |
string |
生成的镜像快照的 UUID。 |
{
"image_id": "0e7761dd-ee98-41f0-ba35-05994e446431",
}
创建服务器备份 (createBackup Action) API¶
带有 createBackup 的 POST /servers/{server_id}/action API 将不会被更改。此 API 创建的镜像快照将使用相同的密钥进行加密。
加密磁盘镜像快照的镜像元数据¶
当创建加密的镜像快照时，其镜像属性将被设置为包含加密信息，当 Nova 将其上传到 Glance 时。有一个 Glance 规范 提出，为所有项目在使用加密 Glance 镜像时建立一组标准化的镜像属性
os_encrypt_format- 主要使用的机制，例如 ‘LUKS’
os_encrypt_cipher- 密码算法，例如 ‘AES256’
os_encrypt_key_id- 密钥管理中的密钥引用
os_encrypt_key_deletion_policy- 在镜像删除时指示是否应该删除密钥
os_decrypt_container_format- payload 解密后的格式，例如‘qcow’
os_decrypt_size- 解密有效负载后的尺寸
这些将被用于 Nova 中的加密镜像快照。
当从加密镜像创建新实例时，镜像属性将通过其在实例的系统元数据中的存在传递到较低层（例如，在调用 qemu-img convert 的较低层，我们不再可以访问镜像元数据，否则需要对多个较低层方法进行非平凡的重构，或者类似的操作）。
由带有临时加密的实例创建的快照¶
当带有临时加密的实例被搁置时，现有的根磁盘加密密钥将被重用，并在以后用于恢复实例。这样做是为了防止在管理员用户搁置非管理员用户实例的情况下，潜在地更改根磁盘加密密钥的所有权。如果创建了一个由管理员用户拥有的新密钥，那么拥有该实例的非管理员用户将无法恢复该实例。
但是，如果我们可以使用实例的用户和项目而不是搁置者的用户和项目来创建新的加密密钥，就可以避免这种行为。如果可以做到这一点，我们就不需要重用加密密钥。
当救援镜像已加密时创建的救援磁盘镜像¶
当救援实例并且指定了加密的救援镜像时，将使用来自镜像属性的救援镜像 secret UUID 来加密救援磁盘。不会创建新的密钥管理器 secret。
使用救援镜像 secret 是因为无论实例是否具有加密的根磁盘，它都将存在。从技术上讲，可以为没有其他加密本地磁盘的实例指定加密的救援镜像。
救援磁盘将在且仅当救援镜像已加密时才会被加密，目的是不从当前处于加密状态的数据中创建未加密的静态数据。
将为救援磁盘创建新的 virt 驱动程序 secret，并在取消救援实例时删除它。
临时加密密钥的清理¶
当相应的实例被删除并且其磁盘被销毁时，临时加密密钥将从密钥管理器和 virt 驱动程序中删除。
virt 驱动程序 secret 可以在目标主机上创建，并在实例迁移期间从源主机上删除。
但是，密钥管理器 secret 仅在与其关联的磁盘被销毁时才会被删除。
创建快照时创建的加密密钥绝不会被 Nova 删除。只有在镜像快照从 Glance 中删除时，才允许删除密钥。在标准化的 Glance 镜像属性中，有一个 os_encrypt_deletion_policy 镜像属性，Nova 将设置为告诉 Glance 在删除镜像的同时删除密钥管理器 secret。
BlockDeviceMapping 更改¶
将扩展 BlockDeviceMapping 对象，以包含封装上述信息的以下字段，每个实例中的临时磁盘
encrypted一个简单的布尔值，指示块设备是否已加密。最初，这仅在临时加密使用时才会被填充，但将来也可以轻松地用于加密的卷。
encryption_secret_uuid顾名思义，这将包含磁盘关联的加密密钥的 UUID。此处使用的密钥类型将取决于所使用的加密格式和 virt 驱动程序，不应假定它始终是当前 Cinder 提供的所有加密卷都是对称密钥。
backing_encryption_secret_uuid对于 qcow2 格式的磁盘，这将包含关联加密密钥的 UUID，用于备份文件。
encryption_format一个新的
BlockDeviceEncryptionFormatType枚举和相关的BlockDeviceEncryptionFormatTypeField字段，列出加密格式。可用的选项将与 os-brick 当前提供的常量保持一致，并且如果两者都可以共享这些类型和字段，则将来可能会合并。encryption_options一个简单的、未版本化的字符串字典，包含特定于 virt 驱动程序实现、底层 hypervisor 和所用格式的加密选项。
注意
可以使用 encryption_options 字段来存储用于创建磁盘的加密参数，例如密码算法、密码模式和初始化向量生成器算法。
目的是能够跟踪每个磁盘的加密属性，以帮助处理未来的升级场景，例如算法的删除或 QEMU 中默认值的更改。
在构建期间填充临时加密 BlockDeviceMapping 属性¶
当通过镜像或 flavor 请求使用临时加密启动实例时，对于 destination_type 值为 local 的每个 BlockDeviceMapping 记录，BlockDeviceMapping.encrypted 属性将被设置为 True。 这将在原始 API BDM 字典转换为 Compute API 中的对象之后，但在调度实例之前发生。
如果提供了，encryption_format 属性也将从镜像或 flavor 获取其值。 如果镜像和 flavor 之间存在差异或冲突，将引发 API 返回 409 Conflict 错误。
使用 COMPUTE_EPHEMERAL_ENCRYPTION 兼容性特征¶
在 Wallaby 期间引入了一个 COMPUTE_EPHEMERAL_ENCRYPTION 计算兼容性特征，virt 驱动程序将报告该特征，以指示对使用这种新方法进行临时存储加密的总体支持。 此特征将始终由以下部分概述的预过滤器使用，在请求了临时加密时，无论请求中是否指定了格式，从而允许最终处理请求的计算选择其支持的格式，使用 [ephemeral_storage_encryption]/default_format 可配置项。
在 Wallaby 期间，还向 os-traits 添加了 COMPUTE_EPHEMERAL_ENCRYPTION_$FORMAT 计算兼容性特征，virt 驱动程序将报告该特征，以指示对特定临时存储加密格式的支持。 例如
COMPUTE_EPHEMERAL_ENCRYPTION_LUKSCOMPUTE_EPHEMERAL_ENCRYPTION_LUKSV2COMPUTE_EPHEMERAL_ENCRYPTION_PLAIN
只有当初始请求中提供了 hw_ephemeral_encryption_format 镜像属性或 hw:ephemeral_encryption_format 额外规格时，这些特征才将与 COMPUTE_EPHEMERAL_ENCRYPTION 特征一起使用。
引入一个临时加密请求预过滤器¶
将引入一个新的预过滤器，当提供上述镜像属性或 flavor 额外规格时，它会将上述特征作为必需项添加到请求规格中。 如上所述，这将始终包括 COMPUTE_EPHEMERAL_ENCRYPTION 特征，在请求了临时加密时，如果请求中包含格式，则可以选择性地包含一个特定于格式的特征。
通过 block_device_info 暴露临时加密属性¶
一旦 BlockDeviceMapping 对象更新并且实例被调度到计算节点，这些对象将再次转换为 virt 层理解的 block_device_info 字典，目前该字典包含以下内容
root_device_name实例使用的根设备路径。
ephemerals一个
DriverEphemeralBlockDevice字典对象的列表，详细说明了附加到实例的临时磁盘。 请注意，这不包括用于实例的初始基于镜像的磁盘，该磁盘在临时加密功能的上下文中被归类为临时磁盘。block_device_mapping一个
DriverVol*BlockDevice字典对象的列表，详细说明了附加到实例的基于卷的磁盘。swap一个可选的
DriverSwapBlockDevice字典对象，详细说明了交换设备。
例如
{
"root_device_name": "/dev/vda",
"ephemerals": [
{
"guest_format": null,
"device_name": "/dev/vdb",
"device_type": "disk",
"size": 1,
"disk_bus": "virtio"
}
],
"block_device_mapping": [],
"swap": {
"swap_size": 1,
"device_name": "/dev/vdc",
"disk_bus": "virtio"
}
}
如上所述，block_device_info 并不提供与实例关联的存储的完整概述。 为了使其在临时存储加密的上下文中有用，我们需要扩展该字典以始终包含与本地基于镜像的磁盘相关的信息。
因此，将引入一个新的 DriverImageBlockDevice 字典类，涵盖基于镜像的块设备，并通过 block_device_info 字典中的一个额外的 image 键提供给 virt 层，当实例使用此类磁盘时。 与其他 Driver*BlockDevice 字典类一样，这将代理访问底层的 BlockDeviceMapping 对象，从而允许 virt 层查找先前列出的 encrypted 和 encryption_* 属性。
虽然超出此规范的范围，但上述内容突出了代码库中存储配置处理方式的巨大复杂性和技术债务。 从长远来看，我们应该计划删除 block_device_info 并将其替换为对基于 BlockDeviceMapping 的对象的直接访问，确保始终将整个配置暴露给 virt 层。
通过元数据 API 报告磁盘处于加密状态¶
扩展元数据 API，以便用户可以确认他们的临时存储是否通过实例中可访问的元数据 API 进行加密。
{
"devices": [
{
"type": "nic",
"bus": "pci",
"address": "0000:00:02.0",
"mac": "00:11:22:33:44:55",
"tags": ["trusted"]
},
{
"type": "disk",
"bus": "virtio",
"address": "0:0",
"serial": "12352423",
"path": "/dev/vda",
"encrypted": "True"
},
{
"type": "disk",
"bus": "ide",
"address": "0:0",
"serial": "disk-vol-2352423",
"path": "/dev/sda",
"tags": ["baz"]
}
]
}
这也应该扩展到由加密卷提供的磁盘，但这显然超出了此实现的范围。
在具有不同 hw:ephemeral_encryption 值的 flavor 之间进行块大小调整¶
预计临时数据将在大小调整过程中保留，因此在配置了临时加密不同的 flavor（一个启用，另一个禁用或格式等）之间进行大小调整将导致我们就地转换此数据。 这并不容易，因此对于此初始实现，在配置了临时加密不同的 flavor 之间进行大小调整将被阻止。
计划在后续补丁中添加在具有不同临时加密参数的 flavor 之间进行大小调整的支持。
提供从遗留实现迁移的路径¶
将引入新的 nova-manage 和 nova-status 命令，以便在未来版本中删除遗留 libvirt virt 驱动程序实现之前，迁移使用该实现的任何实例。
nova-manage 命令将确保任何现有实例的 ephemeral_key_uuid 已设置，其关联的 BlockDeviceMapping 记录将被更新以引用所述密钥，legacy_dmcrypt_plain 加密格式和主机上的配置选项，然后清除 ephemeral_key_uuid。
此外，libvirt virt 驱动程序还将在生成期间尝试迁移具有 ephemeral_key_uuid 设置的实例。 这应该允许至少一些实例在 W 版本中移动，以便在 X 之前进行操作。
nova-status 命令将简单地报告任何 ephemeral_key_uuid 设置但没有相应 BlockDeviceMapping 属性启用的实例的存在。
弃用现在遗留的实现¶
libvirt virt 驱动程序中的遗留实现将在未来版本中弃用，以便在迁移能力到位后删除。
备选方案¶
继续使用透明的主机可配置项，并扩展对其他加密格式（如 LUKS）的支持。
数据模型影响¶
有关上述 flavor 额外规格、镜像属性、BlockDeviceMapping 和 DriverBlockDevice 对象更改，请参见上文。
REST API 影响¶
将创建一个新的 API 微版本，以将加密选项添加到
createImage服务器操作 API。将引入 flavor 额外规格和镜像属性验证，用于提供的任何临时加密选项。
将拒绝在临时加密选项不同的 flavor 之间进行大小调整的尝试。
将允许用户在临时加密选项不同的镜像之间进行重建，但前提是该用户拥有该实例。 将拒绝在临时加密选项不同的镜像之间进行重建的请求。 这是为了防止实例磁盘的密钥所有权发生变化。
元数据 API 将更改为允许用户确定他们的临时存储是否已加密，如上所述。
安全影响¶
希望这会是积极的，因为每个磁盘和用户可见的选择都使用唯一的密钥来加密临时存储。
此外，这应该允许其他 virt 驱动程序支持临时存储加密，同时也允许 libvirt virt 驱动程序扩展对更多镜像后端（如 qcow2 和 rbd）的特性覆盖范围。
通知影响¶
N/A
其他最终用户影响¶
用户可以通过选择镜像或 flavor 来选择使用临时存储加密。
性能影响¶
额外的预过滤器将在调度实例时增加少量开销，但如果未通过镜像或 flavor 请求临时加密，则应该快速失败。
实例增加使用临时存储加密的性能影响留待 virt 驱动程序特定的规范讨论，因为这将因 hypervisor 而异。
其他部署者影响¶
N/A
开发人员影响¶
virt 驱动程序开发人员可以使用新引入的计算兼容性特征来指示对特定临时存储加密格式的支持。
升级影响¶
计算特征应确保在滚动升级期间，使用临时加密的混合计算（N-1 和 N）进行实例调度请求能够正常工作。
如上文所述，未来的升级需要为现有的临时存储加密用户提供迁移到遗留实现的路径。 这应该很简单，但在 W 周期期间可能需要在 CI 中进行额外的炸弹作业来证明迁移路径。
实现¶
负责人¶
- 主要负责人
melwitt
- 其他贡献者
lyarwood
功能联络人¶
- 功能联络人
melwitt
工作项¶
引入
hw_ephemeral_encryption镜像属性和hw:ephemeral_encryptionflavor 额外规格。引入一个新的
encrypted、encryption_secret_uuid、backing_encryption_secret_uuid、encryption_format和encryption_options属性到 BlockDeviceMapping 对象。通过
Driver*BlockDevice层和block_device_info字典连接新的BlockDeviceMapping对象属性。通过元数据 API 报告临时存储加密。
引入新的
nova-manage和nova-status命令，允许现有用户迁移到此新实现。 但是，这应该在 virt 驱动程序实现着陆之前被阻止。在 virt 驱动程序实现着陆之前，将在功能测试中验证所有上述内容。
依赖项¶
无
测试¶
目前，没有 virt 驱动程序实现，这将完全在我们的单元和功能测试套件中进行测试。
一旦有 virt 驱动程序实现，就可以编写额外的集成测试（在 Tempest 中）和白盒测试。
测试从遗留实现迁移的路径将需要一个额外的炸弹作业，但这需要先完成 libvirt virt 驱动程序实现。
文档影响¶
新的主机可配置项、flavor 额外规格和镜像属性应记录在案。
应编写新的用户文档，涵盖从 Nova 角度来看该功能的整体使用。
应更新 BlockDeviceMapping 对象等的参考文档，以记下新的加密属性。
参考资料¶
历史¶
发布名称 |
描述 |
|---|---|
Wallaby |
引入 |
Xena |
重新提出 |
瑜伽 |
重新提出 |
Zed |
重新提出 |
2023.1 Antelope |
重新提出 |
2023.2 Bobcat |
重新提出 |
2024.1 Caracal |
重新提出 |
2024.2 达尔马提安 |
重新提出 |
