策略层重构¶
https://blueprints.launchpad.net/glance/+spec/policy-refactor
在 Glance 中实现 V2 镜像 API 时，引入了洋葱式分层架构。实施分层架构的原因是为了避免在任何一层发生修改时导致其他层出现回归。Glance 具有独立的策略注入层，该层更靠近数据库而不是 API。本规范将作为策略重构的主规范，并包含多个精简规范来解释各自的实现细节。
问题描述¶
当前策略执行发生在策略层。因此，它在概念上与 Glance 架构中实现的对象的绑定。随着 v2 API 的成熟，一个暴露出来的问题是，操作员希望使用策略来控制谁可以发出 API 调用（就像他们可以对大多数其他 OpenStack 服务一样）。然而，在 Glance 中，策略直接影响 Glance 内部处理的对象，而间接影响谁可以发出 API 调用。这使得操作员难以配置 Glance。
此外，在 Glance 中实现安全的 RBAC 时，我们还注意到某些 API 调用会在层级中强制执行多个策略。例如，在 modify_image 策略的情况下，它会强制执行 get_image 策略，而 get_image 策略又会强制执行 get_image_location 策略。这可能会让操作员修改 modify_image 策略时感到困惑，并想知道为什么如果 get_image 策略或 get_image_policy 短路操作，它没有生效。
提议的变更¶
我们需要一种更好的处理策略的方式
主要提案之一是将实际的策略执行移动到 API 层，以便操作员可以轻松地限制对特定调用的访问。大多数 OpenStack 项目都在 API 层附近执行策略，因此这些努力也将使我们与当前策略执行的思路保持一致。
仅在显示特定资源时才强制执行 get_* 策略，而不是为每个 API 调用强制执行它。例如，get_image 策略仅应在向最终用户显示特定镜像时强制执行，而不应用于其他 API 调用，例如更新、删除、上传或下载镜像。
在将策略移近 API 层时，将保持向后兼容性。（注意：此处不考虑与 RBAC 相关的更改。）
目前，我们的单元和功能测试引用的是测试仓库中的 policy.yaml 文件，而我们应该使用默认策略，并在需要时进行覆盖。
为了使用 RBAC 测试新的策略更改，我们需要两个不同的 CI 作业，这些作业将使用旧策略和启用新的 RBAC 标志来运行我们的测试。
注意：上述某些更改将有其自身的精简规范，以进一步讨论实现细节。
备选方案¶
保持原样，并在实施 Secure RBAC 的其他范围内使用变通方法。
数据模型影响¶
无
REST API 影响¶
REST API 没有更改，但请参阅下面的“其他部署者影响”部分。
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
考虑到为 Secure RBAC 相关的项目范围添加的实验性支持，操作员需要了解哪些策略来管理以及如何正确配置它们。此外，在升级到 Xena（或更高版本）期间，可能需要对任何自定义策略进行一些调整和测试。
开发人员影响¶
开发人员需要更加了解策略以及策略执行必须发生的位置。
实现¶
负责人¶
- 主要负责人
dansmith abhishek-kekane
- 其他贡献者
pdeore
工作项¶
将 API 特定的策略检查移动到 API 层
仅在 API 层强制执行 get_* 策略
在数据库层附近强制执行资源特定的策略
策略执行应与安全的 RBAC 结构兼容
测试应使用默认策略，而不是 policy.yaml
新的 CI 作业，用于在启用和禁用 Secure RBAC 的情况下运行 tempest 测试
依赖项¶
无
测试¶
如“工作项”部分所述，我们的单元和功能测试需要在代码中使用我们的默认策略，而不是 policy.yaml 文件。我们还需要新的 CI 作业，用于在启用和禁用 Secure RBAC 的情况下运行 tempest 测试。
文档影响¶
策略在代码中记录，因此在重构发生时将更新文档。
