REST API 策略执行

以下描述了 nova 中策略使用和执行方面的一些不足，以及解决这些问题的益处。每个问题都有一个专门的部分来更详细地描述其根本原因和历史背景。

当前系统存在的问题

以下是现有策略执行系统存在的问题列表

解决上述问题有助于运维人员

  1. 提供灵活且有用的默认设置

  2. 减少编写和维护自定义策略的可能性

  3. 提高部署之间的互操作性

  4. 通过一流的测试和验证提高 RBAC 的可信度

  5. 通过使用一致的策略命名约定来降低复杂性

  6. 安全地向最终用户公开更多功能，使整个 nova API 更易于自助服务，从而减少运维人员代表用户执行操作的运营开销

此外，以下是贡献者可以获得的好处列表

  1. 通过将策略执行隔离到单个层来减少开发人员的维护和成本

  2. 通过使用一致的策略命名约定来降低复杂性

  3. 通过详尽的测试来提高对 RBAC 重构的信心，从而在合并之前防止回归

测试默认策略

测试默认策略对于防止权威回归至关重要。权威回归是指更改意外地允许某人执行或查看他们不应该执行或查看的内容。它也可能是指更改意外地限制用户执行他们曾经有权执行的授权。在重构策略系统的很大一部分之前，这种测试特别有用。例如，在将策略执行逻辑从数据库层拉到 API 层之前，这种级别的测试将非常有价值。

测试文档 描述了开发这些类型测试的过程。

授权不匹配

计算 API 功能丰富，并且已发展到管理物理和虚拟硬件。一些 API 旨在帮助运维人员，而另一些则专门针对最终用户。从历史上看，nova 使用项目范围的令牌来保护几乎所有 API，无论其预期用户如何。使用项目范围的令牌来授权系统级 API 的请求会导致不良的用户体验，并且容易导致角色过载。例如，为了防止每个用户访问违反租户关系的其他硬件级别 API，运维人员需要创建一个 system-admin 或 super-admin 角色，然后重写这些系统级策略以包含该角色。这意味着在项目上拥有该特殊角色的用户可以访问未针对项目跟踪的系统级资源（超visor 信息是特定于系统的信息的示例）。

从 Queens 版本开始，keystone 支持一种专门用于缓解此问题的范围类型，称为系统范围。在计算 API 中使用系统范围可以减少角色过载，减少代码中的专用授权逻辑，并简化策略，从而向用户公开更多功能，而不会违反租户关系。请参阅 keystone 的 授权范围文档，以了解有关范围及其有效使用方法的更多信息。

命名不一致

不一致的策略命名约定散布在大多数 OpenStack 服务中，包括 nova。最近，一项工作引入了一种考虑服务名称、资源和用例的约定。这种新的约定适用于 nova 策略名称。该约定正式 记录 在 oslo.policy 中，我们可以使用策略 弃用工具 来优雅地重命名策略。

整合默认角色

直到 Rocky 版本，keystone 仅确保在安装时提供一个名为 admin 的角色。在 Rocky 中，此支持已扩展到包括 member 和 reader 角色作为 keystone 安装期间的一流公民。这允许服务开发人员依赖这些角色并在其默认策略定义中包含它们。在默认策略中使用一组标准化的角色名称可以提高部署之间的互操作性并减少运维人员的开销。

您可以在 keystone 规范 或 开发人员文档 中找到有关默认角色的更多信息。

隔离的策略执行

策略逻辑和处理本质上是敏感的，并且通常很复杂。它之所以敏感，是因为编码错误可能导致安全漏洞。它之所以复杂，是因为它需要保护的资源和 API 以及它需要支持的大量用例。这些原因说明了将策略执行和处理隔离到隔离的空间中，而不是让策略逻辑渗透到 nova 的不同层。没有将所有策略逻辑放在一个地方会使策略执行系统的演进变得困难，并使策略系统本身变得脆弱。

当前，nova 的数据库和 API 组件包含策略逻辑。在某个时候，我们应该将这些系统重构到一个更容易维护的组件中。在这样做之前，我们应该考虑加强测试覆盖率的方法，以确保我们意识到或防止策略回归。在 API 保护 测试指南 中有示例和文档。

重构硬编码的权限检查

nova 中的策略系统旨在可配置。尽管有这种设计，但有些 API 具有针对特定角色的硬编码检查。这使得配置变得不可能，具有误导性，并且让运维人员感到沮丧。相反，我们可以删除硬编码的策略并确保采用配置驱动的方法，从而减少技术债务，提高一致性，并为运维人员提供更好的用户体验。此外，将硬编码的检查移动到一流的策略规则使我们能够使用现有的策略工具来弃用、记录和演进策略。

细粒度的策略检查

策略应该尽可能细粒度，以确保一致性和合理的默认设置。使用单个策略来保护整个 API 的 CRUD 是限制性的，因为它阻止我们使用默认角色来使对该 API 的委托灵活。例如，用于 compute:foobar 的策略可以分解为 compute:foobar:create、compute:foobar:update、compute:foobar:list、compute:foobar:get 和 compute:foobar:delete。以这种方式分解策略允许我们为可读操作设置只读策略，或为 foobar 资源的创建和管理使用另一个默认角色。oslo.policy 库具有 示例，展示了如何使用弃用的策略规则来执行此操作。