Ceilometer API RBAC - 细粒度基于角色的访问控制

当前 API 的访问控制缺乏细粒度。事实上，只能拥有“全局”管理员角色或项目中的一个简单的“用户”，介于两者之间没有其他选项。

随着即将推出的 Keystone v3 增强功能，我们可以扩展访问控制的细粒度，允许非“全局”管理员，例如域管理员或父项目管理员。

我们将通过在 API 函数上使用装饰器来实现这一点。该装饰器将根据用户/项目角色以及策略 json 文件中指定的规则来控制访问。

acl.py 可以被弃用，因为它唯一的函数是确定用户是否为管理员，而装饰器可以完成此操作。

示例策略扩展

当前的 policy.json 仅验证用户是否为管理员

{
    "context_is_admin": [["role:admin"]]
}

新的规则允许通过方法和扩展的角色来分离访问控制。同时也与 Keystone v3 扩展的功能兼容，其中支持域。

{
     "context_is_admin": [["role:admin"]],
     "admin_or_cloud_admin": [["rule:context_is_admin"],
              ["rule:admin_and_matching_project_domain_id"]],
     "telemetry:alarm_delete": [["rule:admin_or_cloud_admin"]]
}

问题描述

Ceilometer API 当前支持 API 调用的一切或全无身份验证。

这限制了报告 API 的功能，因为管理多个项目的经理必须获得管理员角色或重新限定每个请求以查看多个项目。

限制功能的使用场景包括

  • 管理多个项目的经销商

  • 管理多个项目的域管理员

  • 管理上述情况的支持人员

提议的变更

我们建议通过将访问控制从调用转移到 ACL，应用到 API 方法的装饰器来解决这个问题。每个公开可访问的 API 方法都将有一个指向新的 RBAC 模块的装饰器。RBAC 模块装饰器将使用在 policy.json 中定义的规则来确定调用者对方法的访问权限。

这将允许细粒度、基于角色、特定于方法地访问控制。

它还将 Ceilometer API 与 Keystone V3 域功能以及分层项目提案对齐，因为域或项目都可以用于规则创建。

替代方案

可以将 RBAC 过滤器放在 Pecan Web 服务器的前面。该过滤器将通过调用 Keystone 来验证角色、项目和域来实现 RBAC。

虽然我们认为这是一个合理的解决方案，但它与 Ceilometer API 当前的实现方式不同。它需要在中间件和 Pecan 之间插入一个访问控制过滤器。它还需要对当前 RBAC 方案进行大量的代码更改，该方案在 API 内部处理访问控制。

提议的模型将最大限度地减少代码更改。它将简单地将装饰器语句添加到外部 API 方法，创建一个额外的模块，并对 policy.json 进行配置更改。

数据模型影响

无

REST API 影响

无

安全影响

新模型将提高安全性，因为访问控制将集中在装饰器模块中。在确保每个外部方法都有默认装饰器调用后，除非在策略配置文件 (policy.json) 中更改，否则访问控制将保持为管理员或项目专用。

当前模型将对 ACL 模块的调用放置在 API 代码的各个位置。例如，GET 方法调用 _query_to_kwargs，最终调用 ACL，而 PUT 方法直接调用 ACL。这可能会导致在如何处理新方法中的访问控制或如何更改现有方法的访问控制方面产生混淆。

安全改进包括允许将用户/项目组合授予除功能强大的管理员角色之外的其他角色，并仍然完成有意义的活动。删除具有最高权限的管理员角色并限制访问到尽可能少的操作集是一种改进。

潜在的安全影响在于，这种方法更依赖于角色。如果指定了复杂的规则，但授予权限的 Keystone 角色没有得到严格控制，那么就有更多的机会向用户授予不必要的访问权限。

换句话说，随着可用角色和访问方案的增加，需要管理的内容也更多。

我们认为可以通过仅启用当前的 context_is_admin 规则来交付基本代码来减轻这种风险。这样的配置不会允许额外的 Keystone 角色授予新的权限，除非系统操作员显式地将新规则添加到策略文件中。

Pipeline 影响

无

其他最终用户影响

这不会直接影响 python-ceilometerclient，因为角色及其关联的规则将在 keystone 中建立，并由 Ceilometer API 解释。然而，python-ceilometerclient 将受益于新策略支持提供的安全性提升。例如，收集器代理（或任何其他 ceilometer 服务）可以拥有一个特殊的角色与之关联，从而禁止其他服务（具有管理员状态）将数据发布到数据库。

如果最终用户利用扩展的 RBAC 功能，那么在保护适当的用户和项目角色以匹配策略文件中定义的角色方面，将对最终用户产生影响。

性能/可扩展性影响

无

其他部署影响

默认情况下，部署期间不会产生任何影响。该更改将以一种保留当前访问控制行为的配置方式交付。操作员可以简单地保持所有内容不变，并期望系统像以前一样运行。

如果操作员希望利用此修复程序提供的扩展访问控制功能，将可以选择定义和使用不同的策略文件。此修复程序还将提供与 Keystone v3 功能的兼容性（同样，不是开箱即用的可选功能）。

部署选项

  • 可选的策略配置更改以启用扩展的访问控制

  • 必须显式启用更改才能允许扩展的访问控制，否则它将默认为当前的访问控制行为。

  • 无需对软件包部署进行任何更改。

  • 现有的策略定义文件将继续像当前一样工作，无需进行任何特殊更改。

开发者影响

添加新的 Ceilometer API 端点的开发人员需要将适当的访问控制机制添加到公开的 API 方法中。

实现

负责人

主要负责人

eap-x, fabgia

其他贡献者

eap-x, srinivas-sakhamuri

持续维护者

fabgia, srinivas-sakhamuri

工作项

工作项

  • 实现 RBAC 验证模块

  • 将装饰器应用于所有外部 Ceilometer API 方法（例如 v2/meters 等）

  • 弃用 acl.py 的使用

  • 如果需要，添加 policy.json 规则（可选）

未来生命周期

HP Ceilometer 开发团队积极致力于改进和维护 API 访问控制。我们预见到商业云提供商需要配置访问控制以用于转售和私有云管理。

我们希望积极参与此功能的许多周期的持续开发和维护。

依赖项

  • Keystone v3 采用

  • 不需要新的库或程序

  • 没有外部依赖项

测试

现有的 API 测试将确保保留当前的访问控制功能。新的单元测试将涵盖扩展的功能。

文档影响

需要有关启用扩展 RBAC 功能的文档。

参考资料

Keystone V3 策略：https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json