让 Cinder 保持一致且安全，并支持 RBAC¶
https://blueprints.launchpad.net/cinder/+spec/s-rbac-ready-y
修改 Cinder 的策略定义，以支持一致且安全的默认 RBAC社区目标 [1]。
问题描述¶
Cinder 策略目前仅依赖于角色，不识别范围，而范围是在 Queens 中引入 Keystone 的。因此，实现例如只能执行非破坏性操作的管理员非常复杂且容易出错。（例如，请参阅 Cinder 文档中的策略配置 HOWTO。）
使用令牌范围以及 Keystone Queens 时代的其他改进，例如角色继承，可以定义识别一组有用“角色”的策略规则。如果所有 OpenStack 服务都定义策略规则以支持这一点（即“一致”的部分），则操作员无需重写策略来尝试创建这些角色，而是可以使用经过测试的默认策略（即“安全”的部分）。
用例¶
一些示例
操作员希望拥有一个只能执行非破坏性操作的管理员。
操作员希望在每个项目中使用不同级别的最终用户（例如，一个可以比“项目成员”做更多事情的“项目经理”）。
操作员希望拥有一个系统管理员，可以管理 cinder 服务，但不能干扰属于管理员不是成员的项目拥有的资源。
操作员希望拥有一个客户支持管理员，可以对各种项目拥有的资源执行仅管理员才能执行的操作，但不能修改 cinder 服务。
提议的变更¶
在 Xena 周期中进行的策略更改的描述，在 cinder 代码仓库中的基本策略定义文件中有一段很长的注释，描述了这些更改将如何延续到 Yoga。不幸的是，然而，随着服务开始实施一致且安全的 RBAC，最初的提案中发现了一些问题，导致了该努力的方向发生了变化 [2]。这意味着上述 Yoga 周期中 cinder 的策略 [3]必须完全修改。
方向的改变以以下方式影响 cinder
“system-*”角色被定义为尽可能地对服务本身（而不是项目拥有的资源）起作用。（在 Xena 中，这些角色被设想为 cinder 超级用户，因此能够对项目资源和系统本身执行所有操作。）
“project-admin”角色现在旨在成为一个管理员（即操作员的代表——绝对不是最终用户），可以对项目拥有的资源执行管理员类型的操作（例如，迁移卷）。
引入了一个新的“project-manager”角色。这旨在成为一个最终用户，在项目中比“普通”用户拥有一些额外的权限。例如，可以授予项目经理设置卷类型为项目默认类型的权限。
在 Yoga 中，我们将执行以下操作
Xena 中合并的 Cinder 策略角色和权限文档 [4]包含关于 Yoga 中将要做什么的展望信息。不幸的是，这不再准确。该文档的 stable/xena 版本应修改为仅描述 Xena 中的更改，以免误导操作员关于该努力的方向。
有一个补丁解决了这个问题：https://review.opendev.org/c/openstack/cinder/+/818696
Yoga 开发分支中的 Cinder 策略角色和权限文档需要修改
允许“system-*”角色执行的操作范围将限制为对 cinder 服务的操作。这些将是“系统范围”操作。
允许“project-admin”角色执行的操作范围将允许此人对该人具有“admin”角色的任何项目拥有的资源执行管理操作。这些将是“项目范围”操作。
“project-member”和“project-reader”操作可能不会从 Xena 更改，但它们将在 Yoga 中明确地“项目范围”。
将有一些多范围操作。例如，系统和项目角色都应该能够列出卷类型（尽管只有系统管理员才能创建卷类型）。
一旦文档被修改，我们将能够将“scope_types”字段添加到每个策略规则。
此外，我们将能够更新所有策略的检查字符串。
理想情况下，当 project-admin 发出
GET /v3/volumes?all_tenants=1调用时，例如，响应应包括由所有且仅由该 project-admin 具有“admin”角色的项目拥有的卷。对于 Yoga，我们将允许任何具有“admin”角色的用户查看所有项目的卷（就像现在一样）。（有关原因，请参阅社区目标声明中的“跨部署列出项目资源”的讨论 [5]。）
此时，我们将完成社区目标的第 1 阶段 [6]。这将允许 cinder 随 oslo.policy 配置选项 enforce_scope=True 在 Z 版本中一起发布。（重要的是，社区目标的第 3 阶段 [7]在服务需要 enforce_scope=True 之前无法实施。）
我们计划在 Z 开发周期中执行社区目标的第 2 阶段 [8]。有关详细信息，请参阅社区目标文档。
如上所述，通过在 Yoga 中完成第 1 阶段，我们还应该能够在 Z 开发周期中完成第 3 阶段。
备选方案¶
什么都不做。尽管我们在 Xena 中做了所有这些工作，但这仍然不是一个真正的选择，因为对于某些项目使用范围而另一些项目忽略它，同时在项目之间保持一致的角色是不可能的。因此，如果我们不升级我们的策略定义，我们将阻止所有 OpenStack 云使用一致且安全的策略。
数据模型影响¶
无。
REST API 影响¶
各种 Block Storage API 调用的能力已经由策略控制。
安全影响¶
总的来说，这应该通过向操作员提供一套合适的“角色”，这些角色将在他们开箱即用的项目中一致地运行，从而提高安全性，而不是实施他们自己的角色。
Active/Active HA 影响¶
无。
通知影响¶
无。
其他最终用户影响¶
无。
性能影响¶
没有，我们已经需要向 keystone 发出调用以验证令牌并检索用户权限。
其他部署者影响¶
无。
开发人员影响¶
没有，除了完成实施工作。
实现¶
负责人¶
主要负责人
rosmaita
abishop
其他贡献者
tosky
enriquetaso
eharney
geguileo
whoami-rajat
jobernar
工作项¶
更新 stable/xena 分支中的 Cinder 策略角色和权限文档。
更新 Yoga 策略更改的上述 Cinder 策略角色和权限文档在 master 分支中。
将适当的
scope_types添加到所有策略规则。更新策略检查字符串以将系统策略与项目策略分开。
更新所有测试以反映上述更改，并根据需要添加新测试。
支持系统范围的客户端更改：https://review.opendev.org/c/openstack/python-cinderclient/+/776469
依赖项¶
没有，完成第 1 阶段所需的更改很久以前就在 Keystone 和 oslo.policy 中合并了。
测试¶
继续使用 Xena 中开发的测试框架。
我们继续拥有 Xena 规范中提到的拉伸目标，即在 cinder-tempest-plugin 中进行安全 RBAC 测试，但我们不认为这是成功完成此规范的要求。
文档影响¶
Cinder 的主要面向用户的文档是 Cinder 服务配置指南 中的 策略角色和权限。
此外，我们预计鉴于这项工作的 OpenStack 范围，Keystone 文档中会有更多针对操作员的通用文档。
