Nova 证书验证¶

https://blueprints.launchpad.net/nova/+spec/nova-validate-certificates

OpenStack 现在支持对签名镜像进行签名验证。但是，它不支持对用于生成镜像签名的证书进行强力证书验证。具体来说，nova 没有机制来识别受信任的证书。虽然 nova 使用 cursive 验证已签名镜像的签名，但没有办法确定用于生成和验证该签名的证书是否是用户信任的证书。此更改将引入 nova API 的一项补充，允许用户在创建或重建服务器时指定受信任证书列表。这些受信任证书将与 cursive 中的签名验证结合使用，进行证书验证，从而让用户对正在启动的镜像的身份和完整性充满信心。

问题描述¶

Nova 能够使用 cursive，OpenStack 签名验证库 [2]，来验证已签名镜像的签名。签名验证确保从 glance 获取未修改的镜像数据。然而，当前用于验证用于生成已签名镜像签名的证书的验证仅限于时间戳有效性检查，仅确保证书在签名验证时有效。没有机制来确保使用的证书是最终用户批准的证书。如果攻击者可以访问 glance，他们可以用攻击者证书替换用户的已签名镜像，该证书存储在 OpenStack 部署的证书管理器中，替换成经过修改的恶意镜像。如果要求启动此修改后的镜像，计算服务将检索镜像及其对应的证书，验证镜像签名，然后使用恶意镜像数据启动虚拟机。在 cursive 中提供证书验证支持有助于 nova 检测此攻击场景并采取措施提醒用户潜在的风险。

请注意，此威胁模型将 glance 视为不受信任的，不包括对 nova 的完整性、可用性或机密性的威胁。它假定：（1）攻击者可以访问证书管理器并能够存储用于镜像签名的证书，以及（2）此攻击者无法访问其他用户拥有的任意证书公钥/私钥对。如果攻击者拥有此访问权限，他们将能够冒充用户，替换已签名镜像并根据需要完美地更新相应的镜像签名和元数据以掩盖攻击。

用例¶

Nova 用户希望通过控制用于签名镜像的证书集来确保他们正在启动他们信任的镜像。

通过此更改，nova 用户可以在从已签名镜像创建/重建服务器时，如果启用了签名验证和证书验证，则指定受信任证书的身份。预计其中一个受信任证书是用于生成镜像签名的证书的签名证书。

启用证书验证后，只有当镜像签名证书是由受信任证书生成的时，镜像签名验证才会成功。这允许用户参与签名验证过程，要求成功启动需要有效的证书信息。

请注意，这些受信任的证书存储在独立于计算服务的证书管理器中。对于这项工作，证书管理器是任何由 castellan 支持的服务后端，它提供用于证书对象的管理操作。证书管理通常是通用密钥管理器功能的子集，通用密钥管理器能够管理不同类型的加密密钥（例如，加密密钥、密码）。截至 Pike 版本，barbican（OpenStack 密钥管理服务）是唯一满足证书管理器要求的 OpenStack 服务。在未来，任何由 castellan 支持并提供证书管理的 OpenStack 或第三方服务都可以代替 barbican 使用。

另外请注意，从现有卷启动实例目前与受信任的证书验证不兼容。块存储服务没有将受信任的证书与存储在卷中的镜像数据关联的方法。如果启用了受信任的证书验证并从卷启动实例，则无法进行证书验证。因此，所有尝试从卷启动并进行证书验证的操作都将导致构建错误。

提议的变更¶

支持证书验证需要进行一些更改。最初的更改添加了一对新的配置选项。第一个配置选项，enable_certificate_validation，将在进行镜像签名验证时启用 cursive 证书验证例程（参见下面的第五个更改）。只有当 verify_glance_signatures 设置为 True 时，此选项才会被使用，并且默认值为 False，允许在计算部署完全升级之前进行签名验证而无需证书验证。如果将此选项设置为 True，则将执行证书验证。

第二个配置选项 default_trusted_certificate_ids 将包含一个由计算部署信任的证书 ID 列表。只有在未启用证书验证并且用户未提供受信任证书 ID（参见下面的第二项和第三项更改）时，才会使用此受信任证书 ID 列表。此列表应由管理员定义，因为它将是计算部署的默认受信任证书 ID 集。此选项的默认值将是一个空列表，如果留空，则需要用户提供的受信任证书 ID 集。如果用户提供了受信任证书 ID 的列表，则将忽略默认受信任证书 ID 的列表。

上述两个配置选项已经实现并合并到 nova 中。有关实现细节，请参阅 [9]。

第二个更改为 nova API 的服务器创建命令添加了一个参数，trusted_image_certificates。该参数的值是一个列表，包含用于验证已签名镜像的签名证书的受信任证书的字符串 ID。这些 ID 是在上传受信任的证书时由证书管理器分配的。为了给用户提供灵活性，这里允许使用多个 ID。用户可能无法知道哪个特定证书对应于他们的镜像。允许用户定义一组受信任的证书可以消除镜像/证书映射的需求，从而简化用户体验。如果提供，nova 将将这些值传递给 cursive 中的证书验证例程，覆盖默认的受信任证书 ID 列表（参见上面的第二个配置选项）。Cursive 将使用它们使用 castellan 获取受信任的证书。如果提供，该参数的值将被保存并将在服务器数据的整个生命周期内持续存在。

第三个更改为 nova API 的服务器重建命令添加了一个参数，trusted_image_certificates。此参数与上述第一个更改中描述的参数相同。此参数是可选的，并且在用非签名镜像重建服务器或未启用证书验证时，nova 会忽略该参数。如果提供，该参数的值将被保存并将在服务器数据的整个生命周期内持续存在。如果在用已签名镜像重建服务器时未提供该参数，则与服务器关联的先前的一组受信任的证书 ID 将被保留。

上述两个更改已经实现，正在等待 nova 的进一步反馈。有关更多信息，请参阅 [14]。

第四个更改添加了一个证书验证上下文来执行证书验证。这项工作将与 cursive 新的 certificate_utils 模块中的签名验证例程一起进行。验证上下文存储一组任意证书，并使用它们来验证提交用于证书验证的单个证书。上下文尝试为提交的证书构建证书链，通过加密方式验证链中的每个父证书都已对其子证书进行签名。pyca/cryptography 用于执行所有证书和加密操作。该上下文还检查各种约束，以确定证书是否有效，包括有效的有效时间戳检查。如果上下文无法为提交的证书构建有效的证书链，或者如果任何证书约束检查失败，则提交的证书验证将失败。

上述更改已经实现并合并到 cursive 中。有关更多信息，请参阅 [10]。

第五个更改将证书验证例程集成到签名验证工作流程中。当证书验证例程获取镜像的签名证书时，它将使用用户提供的受信任证书（参见上面的第一项和第二项更改）构建验证上下文。然后，它将签名证书通过上下文进行证书验证。如果验证成功，则可以像往常一样继续进行签名验证。如果验证失败，则签名验证也会失败，服务器将被置于 ERROR 状态，并将错误返回给用户。

上述更改已经实现，正在等待 nova 的进一步反馈。有关更多信息，请参阅 [13]。

如果 (1) nova 未配置为进行证书验证，并且 (2) 用户提供了受信任的证书 ID，期望进行证书验证，则可能会发生静默失败的情况。在这种情况下，nova 不会进行证书验证并启动实例，导致用户认为证书验证成功，尽管它从未发生。为了防止这种情况发生，启动工作流将被更新为如果实例数据与受信任的证书 ID 相关联，则进行签名和证书验证。这符合用户的期望，并防止发生静默失败的情况。请注意，此覆盖仅在用户指定证书 ID 时发生。默认的证书 ID 列表仅在启用该功能时使用，因此永远不会触发覆盖。

第六个更改更新了 nova 数据模型，以支持服务器操作期间的证书验证，例如服务器撤离和冷迁移或实时迁移。更普遍地说，这适用于管理员对服务器执行的任何操作，而无需最终用户最初提供给 nova 启动命令的所有信息。为了支持这些情况，用于证书验证的受信任的证书 ID 必须与实例数据一起存储，因为不能期望用户提供它们。nova 中的 InstanceExtra 功能已经支持与实例关联的密钥对。此更改将更新 InstanceExtra 模式以支持 trusted_certs 列，该列将包含受信任的证书 ID 列表。底层的存储将利用 oslo versionedobjects，为实例添加一个新的 TrustedCerts 对象以供引用。

上述更改已经实现，正在等待 nova 的进一步反馈。有关更多信息，请参阅 [11] 和 [12]。

第七个更改更新了 InstancePayload 通知基础，将受信任的证书 ID 添加到创建实例和重建实例的通知中。这将帮助用户和管理员识别他们的实例何时利用证书验证，并有助于诊断验证失败时发生的情况。

第八个更改更新了从卷启动实例的控制流程，拦截这些请求（如果启用了证书验证），并生成构建失败。在底层块存储服务支持将受信任的证书信息映射到实例数据 [19] 之前，无法支持这些情况。

第九个更改添加了围绕受信任证书使用的新策略规则，允许 nova 管理员轻松启用/禁用证书验证（如果他们的部署可以/不能支持该功能）。具体来说，将为服务器创建和重建请求添加新的策略规则。如果提出任何请求并提供了受信任的证书，则策略检查器将验证该操作是否允许。如果不是，将引发 PolicyNotAuthorized 异常以使请求失败。这在部署支持从卷启动（参见上面的第七个更改）或支持基于 libvirt 以外的虚拟化驱动程序时很有用。

第十个更改更新了 novaclient/openstackclient，以支持服务器创建/重建命令的 trusted_image_certificates 参数。这包括对新环境变量 OS_TRUSTED_CERTIFICATE_IDS 的支持，该变量可用于定义逗号分隔的受信任证书 ID 列表。如果未使用 trusted_image_certificates 参数，则客户端将提取环境变量的值并使用它。该值将在传递之前转换为列表。

上述更改已经实现，正在等待进一步的反馈。有关更多信息，请参阅 [15] 和 [16]。

如果用户未提供 trusted_image_certificates 参数的值，无论是显式提供的还是通过 OS_TRUSTED_CERTIFICATE_IDS 环境变量提供的，nova 将从 default_trusted_certificate_ids 配置选项中提取受信任的证书 ID 列表。如果将此选项保留为空列表，则 nova 将无法获得用于证书验证的受信任证书。在这种情况下，将无法确定镜像的签名证书是否受信任，从而导致签名验证失败，进而导致服务器创建失败。

第十一个也是最后一个更改更新了服务器 show 命令的输出，以包含存储在服务器实例数据中的受信任的证书 ID 列表。如果服务器实例数据中未存储任何证书 ID，则服务器 show 命令的输出仍然包含新的键 trusted_image_certificates 在响应中，就像 tags 一样。这样做是为了避免混淆最终用户，他们已经对给定的微版本发出了请求，期望看到服务器是否关联了证书。

备选方案¶

这里证书验证的另一种方法是支持证书信任库，这些信任库是与单个用户或项目关联的受信任证书的集合。在创建新服务器时，用户将指定他们的信任库作为受信任证书的来源，从而替换 trusted_image_certificates 参数中提供的证书列表。有许多方法可以支持信任库，包括：包含存储在计算主机上的本地受信任证书文件的文件系统目录信任库、由 nova 或 keystone 等服务支持的元数据/托管资源方法，以及由 barbican 等服务支持的基于容器的密钥存储方法。虽然信任库在定义受信任证书的集合方面很有用，但它们可能难以扩展到大型云部署，从而带来管理和维护方面的挑战。信任库还引入了一种用户必须信任的新结构，特别是如果用户不直接负责维护他们的信任库。

用户提供受信任证书或将受信任证书存储在信任库中的替代方法是使用存储在正在验证的签名证书的 Private Internet Extension 中的信息动态获取证书。这种方法允许部署者和用户使用签名证书，而无需预先获取完成证书验证过程所需的所有根证书和中间证书。但是，这种方法需要计算服务具有对所有可能的证书存储库的持久网络访问权限，这些存储库可能存储根证书和中间证书。在许多情况下，这将包括对公共互联网的网络访问，这对于通用部署而言可能不可行。

增强的证书验证例程将包括证书撤销，支持常用的方法，例如证书撤销列表 (CRL) 和/或在线证书状态协议 (OCSP)。支持证书撤销将允许计算服务动态确定证书何时因泄露而失效，从而进一步提高启动签名镜像的安全性。但是，支持证书撤销涉及动态获取和信任网络资源，通常由第三方控制和授权。这对于某些部署而言可能不可行。可以将证书撤销集成到计算服务之外，例如在证书管理器或通过另一个第三方服务中。这将使 nova 获得及时的撤销的好处，而不会使 nova 本身中的签名验证和证书验证功能复杂化。

应该注意的是，此功能的未来工作将添加对证书撤销的支持。

数据模型影响¶

InstanceExtra 数据库模型将被更新，以包含一个新的文本列，trusted_certificate_ids，它将包含与服务器创建/重建请求一起提供的受信任的证书 ID 列表。如上所述，如果未在服务器请求中包含 ID，则将从 default_trusted_certificate_ids 配置选项中提取它们。与 InstanceExtra 中的现有字段一样，此添加将利用 oslo versionedobjects 来存储列表，需要添加一个 trusted_image_certificate_id 字段。

REST API 影响¶

以下是向 (1) 从已签名镜像创建新服务器和 (2) 从已签名镜像重建服务器发送请求的示例，包括新的 trusted_image_certificates 参数。此更新将在新的 API 微版本下完成。

{
    "server": {
        "name": "example-name",
        "imageRef": "70a599e0-31e7-49b7-b260-868f441e862b",
        "flavorRef": "http://openstack.example.com/flavors/1",
        "trusted_image_certificates": [
            "00000000-0000-0000-0000-000000000000",
            "11111111-1111-1111-1111-111111111111",
            "22222222-2222-2222-2222-222222222222"
        ],
        "metadata": {
            "My Server Name": "Example Signed Server"
        }
    }
}

{
    "rebuild": {
        "name": "example-name",
        "imageRef": "70a599e0-31e7-49b7-b260-868f441e862b",
        "trusted_image_certificates": [
            "00000000-0000-0000-0000-000000000000",
            "11111111-1111-1111-1111-111111111111",
            "22222222-2222-2222-2222-222222222222"
        ],
        "metadata": {
            "My Server Name": "Example Signed Server"
        }
    }
}

请注意，虽然在这些示例中 trusted_image_certificates 中的值是 UUID，但不能保证如此。证书管理器使用不同的 ID 分配方案；虽然有些使用严格的 UUID，但有些使用简单的递增整数或原始十六进制字符串。对于此功能，trusted_image_certificates 的类型将是一个包含零个或多个 JSON 字符串值的数组。

以下是 trusted_image_certificates 参数的 JSON 模式描述

{
    "type": "array",
    "minItems": 0,
    "maxItems": 50,
    "uniqueItems": true,
    "items": {
        "type": "string"
    }
}

请注意 trusted_image_certificates 参数中包含的证书 ID 的上限和下限。如果对已签名镜像进行 API 调用并超过允许的证书 ID 数量上限，则 API 调用将失败。

安全影响¶

通过此功能提供的附加验证步骤，启用的情况下，提高了已签名镜像验证功能的安全性。

通知影响¶

随着将受信任的证书信息添加到 InstanceExtra 数据模型，创建实例和重建实例的通知应更新为包含特定实例的受信任的证书 ID。具体来说，InstanceCreatePayload 和 InstanceActionRebuildPayload 应更新为包含一个“trusted_image_certificates”字段，该字段将包含与通知关联的实例的受信任的证书 ID 列表。

其他最终用户影响¶

此更改对可以用于签名镜像的证书施加了额外的限制，如果与在启用该功能之前签名的镜像一起使用，可能会导致迁移挑战。

迁移需要用户将受信任的证书上传到证书管理器，如果他们打算在创建或重建请求中指定它们的话。所有镜像签名证书必须已经存在于证书管理器中，以支持签名验证。

随着对 OS_TRUSTED_CERTIFICATE_IDS 环境变量的支持的添加，鼓励用户通过他们的 openrc 文件设置该变量，以及他们的身份验证凭据。OS_TRUSTED_CERTIFICATE_IDS 环境变量的值是受信任证书 ID 的逗号分隔字符串，该字符串将被转换为 trusted_image_certificates 参数的证书 ID 列表。

以下是一个示例 openrc 文件，它使用与 API 示例中相同的受信任证书 ID（请参阅上文的 REST API 影响）。

export OS_USERNAME=username
export OS_PASSWORD=password
export OS_TENANT_NAME=projectName
export OS_AUTH_URL=https://identityHost:portNumber/v2.0
export OS_TRUSTED_CERTIFICATE_IDS=00000000-0000-0000-0000-000000000000,111111
11-1111-1111-1111-111111111111,22222222-2222-2222-2222-222222222222

请注意，在此示例中，第二个证书 ID 被拆分以满足此规范的行换行格式。在实际的 openrc 文件中，不应使用显式的换行符。

性能影响¶

Nova 将通过 cursive 每次执行签名验证时加载用户的受信任证书。根据证书的大小和数量以及签名验证的频率，这可能会给计算服务带来性能负担。为了缓解这种情况，请参阅上述“替代方案”部分，了解有关持久证书信任存储以及从远程存储动态加载证书的信息。

其他部署者影响¶

包含两个新的配置选项，enable_certificate_validation 和 default_trusted_certificate_ids，将有助于为希望启用此功能的部署平滑过渡。如果启用这些选项，在启动签名镜像时，所有先前对服务器创建/重建 API 的使用都将失败，如果无法找到受信任的证书。

添加控制证书验证使用情况的新策略规则将使管理员能够轻松启用或禁用该功能（如果他们的部署支持与证书验证不兼容的其他功能，例如支持从卷启动和基于非 libvirt 的虚拟化）。

开发人员影响¶

无

升级影响¶

无

实现¶

负责人¶

主要负责人: Peter Hamilton

工作项¶

添加两个新的配置选项，enable_certificate_validation 和 default_trusted_certificate_ids。第一个将在启用签名验证时启用证书验证的使用。第二个将提供一个默认的受信任证书 ID 列表，如果服务器请求中未提供受信任的证书 ID，则可以使用该列表。请参阅 [9]。
更新 cursive 以支持证书验证。这包括添加证书验证上下文类和 verify_certificate 例程，该例程从证书管理器加载证书并使用证书验证上下文进行证书验证。请参阅 [10]。
更新 nova 中现有的签名验证工作流，以合并证书验证，使用 cursive 中的 verify_certificate 例程来验证签名证书。请参阅 [13]。
更新 InstanceExtra 数据库模型，以包含一个新的文本列，trusted_certificate_ids。将包含数据库迁移以在更新/降级数据库模式时添加/删除此列。请参阅 [11] 和 [12]。
为 nova API 的服务器创建和重建命令添加一个新的参数，trusted_image_certificates。该参数的值需要在从 glance 下载镜像时传递到签名验证步骤。请参阅 [14]。
将一个新的通知字段“trusted_image_certificates”添加到 InstanceCreatePayload 和 InstanceActionRebuildPayload。请参阅 [20]。
修改从卷启动实例的控制流程，以便在启用证书验证时生成构建错误。
添加新的策略规则，以允许简单地启用/禁用证书验证的控制（如果部署支持与证书验证不兼容的功能）。
更新 novaclient 以支持 trusted_image_certificates 参数。
更新 novaclient 以提取 OS_TRUSTED_CERTIFICATE_IDS 环境变量的值（当用户未提供 trusted_image_certificates 参数时）。
更新 openstackclient 以支持 trusted_image_certificates 参数。
更新 openstackclient 以提取 OS_TRUSTED_CERTIFICATE_IDS 环境变量的值（当用户未提供 trusted_image_certificates 参数时）。

依赖项¶

这项工作依赖于创建和部署一个 gate-tempest-dsvm-security-ubuntu-xenial 作业，该作业使用带有签名镜像和 barbican 作为证书管理器的 tempest 运行。有关此工作的更多信息，请参阅相应的 tempest 蓝图 [6]。

测试¶

将包含单元测试来测试 nova、novaclient 和 openstackclient 中实现的功能。还将实现 Tempest 测试，以测试 glance 和 nova 之间的端到端功能。请参阅 [17] 和 [18]。

文档影响¶

需要添加关于 trusted_image_certificates API 参数和两个新配置选项的文档，以及定义 OS_TRUSTED_CERTIFICATE_IDS 环境变量及其用法的说明。

参考资料¶

[1] “Nova 签名验证。” 在线：https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/image-verification.html

[2] “Cursive。” 在线：https://launchpad.net/cursive

[3] “清理 signature_utils 代码。” 在线：https://blueprints.launchpad.net/nova/+spec/signature-code-cleanup

[4] “使用 cursive 进行签名验证。” 在线：https://review.openstack.org/#/c/351232/

[5] “扩展 Extras 功能。” 在线：https://review.openstack.org/#/c/343939/

[6] “创建实验性 gate 作业以测试 Nova 的镜像签名验证。” 在线：https://blueprints.launchpad.net/tempest/+spec/image-signing-experimental-gate

[7] “在 Nova 镜像签名验证中使用受信任证书的选项。” 在线：http://lists.openstack.org/pipermail/openstack-dev/2016-October/105454.html

[8] “pyca/cryptography。” 在线：https://github.com/pyca/cryptography

[9] “添加证书验证的配置选项。” https://review.openstack.org/#/c/457678/

[10] “添加证书验证。” https://review.openstack.org/#/c/357202/

[11] “添加 trusted_certs 对象。” https://review.openstack.org/#/c/489408/

[12] “将 trusted_certs 添加到 instance_extra。” https://review.openstack.org/#/c/537897/

[13] “实现 certificate_utils。” https://review.openstack.org/#/c/479949/

[14] “将 trusted_certificates 添加到 REST API。” https://review.openstack.org/#/c/486204/

[15] “微版本 2.61 - 添加 trusted_image_certificates。” https://review.openstack.org/#/c/500396/

[16] “将 trusted_image_certificates 添加到 server。” https://review.openstack.org/#/c/501926/

[17] “添加 Nova 微版本 2.61 的新模式。” https://review.openstack.org/#/c/526485/

[18] “添加证书验证场景测试。” https://review.openstack.org/#/c/515210/

[19] “支持镜像签名验证。” https://review.openstack.org/#/c/384143/

[20] “添加 trusted_certs 的通知支持。” https://review.openstack.org/#/c/563269/

历史¶

鉴于此规范涉及 nova 中的安全功能，它已收到 OpenStack 社区的广泛审查。以下是此提案历史记录的简要时间表，每个开发周期期间记录了主要更改。

..list-table:: 修订版本

header-rows:: 1

- 发布名称
- 描述
- Newton
- 发布草稿
- Ocata
- 提交进行官方审查
- Pike
- 重新提交进行官方审查
- 已批准
- Queens
- 重新提交进行官方审查
- 已批准
- Rocky
- 重新提交进行官方审查
- 已批准
- 修改并重新提交以供官方审核

Newton¶

此规范的初始版本是在 Newton 开发周期的末尾发布，为 Ocata 做准备，重点是基于计算主机文件系统并由云管理员管理的证书信任存储实现。版本 2、3 和 4 涉及次要的格式和语法更新。

版本 5 收到 nova 核心团队的反馈，重点关注 (1) 受信任证书管理与租户用户之间更紧密的集成需求，以及 (2) 大型云中分布式证书文件管理可能存在的可扩展性问题。还通过向 openstack-dev 邮件列表发布 [7] 征求了社区的更多反馈。

版本 6 更新了提议的方法，保留了基于文件系统的证书信任存储，同时添加了对 nova API 的更新。此 API 更改允许用户在创建新实例时指定受信任的证书 ID。

Ocata¶

版本 7 结合了 Ocata 设计峰会收到的反馈，正式删除了基于文件系统的证书信任存储方法，并完全专注于更新 nova API，以允许用户在创建新实例时提交一组受信任的证书 ID。

版本 8 解决了 nova 核心团队的进一步反馈，包括

强调 barbican 是唯一支持的 castellan 后端
更新 nova API 更改以包括重建操作
更新 nova 数据模型以支持将受信任的证书 ID 集合与实例数据一起存储在 instance_extras 中，从而支持自动操作，例如实例撤离和冷/热迁移

Pike¶

版本 9 复制了版本 8，为 Pike 审查过程提供了一个干净的开端。版本 10 解决了次要的空格和规范格式错误。

版本 11 添加了 Pike 规范模板中的新“历史记录”部分，并结合了对版本 9 收到的反馈，澄清了 API 细节并重新排序了“安全性”、“其他最终用户”和“其他部署者影响”部分。

版本 12 解决了进一步的审查员反馈，澄清了 nova 对 API 更改的处理，并解决了规范细节中的差异。

版本 13 更新了规范，以反映 cursive 集成到 nova 中，将证书验证代码移动到 cursive 中。

版本 14 添加了两个新的配置选项，以平滑过渡到使用证书验证，此外还澄清了 oslo versionedobjects 用于修改 InstanceExtra 的用途。

Queens¶

第 15 版和第 16 版复制了第 14 版，为 Queens 审核过程提供了一个干净的基础。第 17 版添加了有关合并和激活的补丁的信息，这些补丁实现了规范中详细描述的各种更改。

第 17 版添加了详细信息，解决了无声失败场景，有条件地将证书信息包含在服务器元数据中，以及其他一些小的修复。

Rocky¶

第 18 版复制了第 17 版，为 Rocky 审核过程提供了一个干净的基础。第 19 版添加了小的更新，包括更新的蓝图和代码审查链接。

第 20 版整合了审核者的反馈，包括实例通知的更新、新策略规则的包含以及在使用从卷启动时证书验证相关的错误处理。

Nova 证书验证