Events RBAC via Policy¶
OpenStack 需要支持针对 ceilometer 事件的细粒度、可定制的基于角色的访问控制 (RBAC)。策略应该依赖于 policy.json，而不仅仅是硬编码。
https://blueprints.launchpad.net/ceilometer/+spec/events-rbac
问题描述¶
目前 ceilometer 的 /events REST API 中唯一的 RBAC 验证是硬编码逻辑，用于限制对管理员的请求。这不够细粒度。在多租户环境中，必须提供限制事件数据的机制，使其仅限于请求中提供的 token 的范围（例如，一个项目的管理员不应能够查看另一个项目的事件）。还应有一种允许非管理员访问某些事件的方式（例如，与其资源相关的事件）。这个问题最初被提出为一个 bug [1]。
提议的变更¶
本蓝图建议对 ceilometer 的 /events REST API 的行为进行以下更改
将以下规则添加到 ceilometer 的默认 policy.json
“telemetry:events:index”: “role:admin” “telemetry:events:show”: “role:admin”
修改代码以使用这些检查来确定允许谁请求事件列表（index）或特定事件（show）。这种模式与其他 OpenStack 项目保持一致。
进一步修改代码，如果/当这些检查通过时，根据 token 的范围过滤将返回哪些事件。如果 token 是针对管理员用户的（通过检查 policy.json 中的特殊 context_is_admin 规则确定），则仅返回与提供的 X-Auth-Token 作用域的项目对应的事件。这与其他项目也一致。如果 token 是针对非管理员用户的，则进一步过滤结果，仅返回与提供的 X-Auth-Token 作用域的用户以及项目对应的事件。
只有当用户传递项目作用域的 token 时，才会处理事件 REST API。这是根据项目过滤事件所必需的。如果用户传递未作用域或域作用域的 token，将抛出 403 错误。
可能存在没有记录项目/用户信息的事件。大多数（如果不是全部）事件都应该具有项目/用户信息，因此事件生成代码需要修改为在创建未来事件时包含这些信息。更新数据库中的现有事件不在本规范的范围内。在所有事件都具有项目/用户信息之前，缺少此数据的事件将与 token 项目对应的事件一起返回，如果该项目的 token 用户是管理员。
对于首次实现，将使用常见的名称保留特性来存储项目/用户信息。
替代方案¶
我们可以使用 policy.json 检查来过滤结果以及确定是否允许请求。这不符合 policy.json 的角色和目的，并且可能对性能产生重大影响。
考虑将项目/用户信息存储在基本属性而不是特性中。从长远来看，这可能更好，但关于在某些事件不作用于项目/用户时使用基本属性的适当性存在一些争论。首先使用特性实现将帮助我们确定这是否是有效的情况。以后可以切换到基本属性。
与其在单个响应中返回项目/用户作用域事件和未作用域事件，我们可以为用户希望获取未作用域事件时需要一个单独的 API 调用。例如，/broadcasts 而不是 /events。由于尚不清楚我们最终是否会得到没有项目/用户信息的事件，现在考虑这一点还为时过早。
我们可以创建另一个策略检查来确定是否应将非管理员角色视为 /events API 目的的管理员（从而能够查询整个项目的事件，而不仅仅是他们自己的事件）。但是，由于预计事件将像计量器 (gnocchi) 和警报 (aodh) 一样从 ceilometer 中分离出来，这似乎是一个短期解决方案。
我们可以支持域作用域的 token，允许域管理员使用单个请求查询整个域的事件。这在未来可能需要，但似乎不需要作为这项工作的一部分来完成。并且等待 keystone reseller 规范 [2] 的实现可能是有益的。
数据模型影响¶
没有，只要我们坚持使用特性。
REST API 影响¶
在更改之前，任何项目的管理员在响应 GET /events 请求时都会看到每个项目的事件，现在 GET /events 将过滤掉属于请求的 auth token 作用域项目之外的事件。这关闭了一个安全漏洞，该漏洞允许一个项目的管理员获取有关他们在该项目中没有角色的另一个项目的信息。
安全影响¶
这将默认情况下大大提高安全性。它还将为运营商提供定制与事件相关的策略的机制，因此利用此功能的运营商需要考虑其配置更改的潜在安全影响。
Pipeline 影响¶
无
其他最终用户影响¶
无
性能/可扩展性影响¶
基于项目/用户的过滤可能会对性能产生轻微的负面影响，但应该通过可能更实质性的性能改进（即向调用者返回更少的数据）来抵消这一点。
通过相同的 API 查询允许没有项目/用户信息的事件将意味着进行两次内部调用（一次获取作用于项目/用户的事件，另一次获取未作用于项目/用户的事件），然后合并它们。这可能会对性能产生轻微的负面影响。
其他部署影响¶
从以前的版本更新需要包括迁移到包含新检查的新版本的 policy.json，否则这些检查将解析为默认值，即允许任何人。
开发者影响¶
无
实现¶
负责人¶
- 主要负责人
edmondsw
- 其他贡献者
dikonoor
工作项¶
检查 context_is_admin 以确定适当的响应过滤
检查 policy.json 以确定是否允许请求
将项目/用户添加到当前缺少这些详细信息的事件
未来生命周期¶
这本质上是一个大型 bug 修复，而不是一项功能。因此，Telemetry 计划的所有成员都应确保它不会再次中断。
在“替代方案”部分讨论了几个潜在的未来增强功能。如果有人希望在未来选择其中任何一项，预计需要单独的规范。
依赖项¶
无
测试¶
单元测试就足够了。
文档影响¶
开发人员文档 [3] 将更新为将 user_id 添加到默认特性的列表中，并解释非管理员只能查看具有其 user_id 的事件，而管理员只能查看具有其 tenant_id 加上未与项目（也称为租户）关联的事件的事件。
参考资料¶
[1] https://bugs.launchpad.net/ceilometer/+bug/1461767 [2] https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst [3] https://docs.openstack.org/developer/ceilometer/events.html
