按资源策略控制¶
https://blueprints.launchpad.net/searchlight/+spec/per-resource-type-policy-control
问题描述¶
当前的策略控制允许我们限制谁可以查询、列出插件或检索方面，使用 oslo 策略引擎 [1]。OpenStack 正在朝着支持更细粒度的控制方向发展，对于 Searchlight 而言，朝着这个方向迈出的一步是允许对单个资源类型进行控制。例如，在给定的云环境中，可能不允许非管理员用户搜索特定的资源类型。从长远来看，这使我们能够转向基于策略控制定义的 RBAC 模型；而不是我们为每个插件使用的硬编码的基于项目的 RBAC，我们可以用项目使用的典型 is_admin_or_owner 策略规则来替换或增强它。
提议的变更¶
提议的更改将允许 policy.json 包含针对单个插件的规则。规则 resource:<resource type>:allow 将控制对插件的整体访问权限。此外，allow 可以替换为其他操作，以允许更精确的控制。例如，规则可能是
"default": "",
"resource:OS::Glance::Image:allow": "@",
"resource:OS::Glance::Image:facets": "is_admin:True"
"resource:OS::Nova::Server:query": "!"
未来的扩展可能会将其扩展为通过策略支持 RBAC 规则规范。例如，以下规则可能转换为我们今天拥有的现有 RBAC 查询
"admin_or_owner": "is_admin:True or project_id:%(project_id)s",
"resource:OS::Nova::Server:allow": "admin_or_owner",
如果资源未通过策略允许，它将被从要搜索的类型列表中删除；如果这导致没有允许的类型，搜索将返回一个空结果集。
备选方案¶
在 setup.cfg 中完全禁用插件是可以使用当前代码库完成的一种可能性。
禁用非管理员的索引需要进行一些更改。
理想的长期解决方案（也是本提案推动的方向）是像 horizon 一样使用服务 policy.json 文件。最终，硬编码的 RBAC 规则在许多情况下可以表示为策略规则，从而提供更大的配置灵活性（例如，将对资源的访问限制为创建它的用户，而不是项目/租户）。这将使保持 Searchlight 部署与每个服务部署的规则同步更容易。
