为策略添加范围¶
https://blueprints.launchpad.net/oslo?searchtext=add-scope-to-policy
本文档详细说明了扩展 oslo.policy 以包含范围属性的优势和所需工作。
问题描述¶
目前有几项举措正在进行中，旨在使开发人员和部署人员更容易使用和理解基于角色的访问控制 (RBAC)。
第一项是社区范围内的 目标，即将所有策略注册到代码中，并像对待配置一样对待它们。 这对部署人员有很多好处，并简化了维护，尤其是升级。
第二项是引入一种与系统级策略或操作自然契合的范围的能力。 目前，OpenStack 的身份服务允许用户在域和项目级别获取授权。 在处理作用于项目或域拥有的资源的 API 时，这很有意义。 在处理超出项目范围的操作（例如修改端点或列出虚拟机监控程序）时，很难将项目甚至域范围重新用于这些操作。 这通常会导致最终用户和部署人员感到困惑。 除了困惑之外，这使得操作员很难正确隔离项目操作与系统操作（请参阅 bug 968696）。 因此，正在努力在 OpenStack 中引入提升的范围，使该问题的解决方案更容易理解和实施。 有关实际方法的更多信息，请参阅相关的身份规范
如果上述方法被接受，则需要记录项目中每个操作的范围。 我们可以利用 oslo.policy 库来做到这一点，因为社区已经倾向于使用该库来记录和注册代码中的默认策略。
用例¶
作为操作员，我需要了解操作应用的级别。
作为开发人员，我希望通过代码强制执行特定操作的范围。
提议的变更¶
oslo.policy 库当前有一个 DocumentedRuleDefault 对象，用于在代码中注册策略并记录它。 我们可以扩展此对象以支持一个额外的属性，该属性表示操作的范围。 考虑以下两个示例
from oslo_policy import policy
...
policy.DocumentedRuleDefault(
name=SERVERS % 'create',
check_str=RULE_ADMIN_OR_OWNER,
description='Create a server.',
operations=[
{'method': 'POST',
'path': '/servers'}
]
)
...
policy.DocumentedRuleDefault(
name=base.IDENTITY % 'create_user',
check_str=base.RULE_ADMIN_REQUIRED,
description='Create a user.',
operations=[
{'method': 'POST',
'path': '/v3/users'}
]
)
这两个规则都描述了它们的作用，但它们没有包含它们打算运行的范围。 实例必须属于一个项目，用户可以在全局范围内或在特定域内存在。 以下表示更好，因为它们更容易理解，并且有助于在策略执行期间强制执行必要的范围
from oslo_policy import policy
...
policy.DocumentedRuleDefault(
name=SERVERS % 'create',
scope_type=['project'],
check_str=RULE_ADMIN_OR_OWNER,
description='Create a server.',
operations=[
{'method': 'POST',
'path': '/servers'}
]
)
...
policy.DocumentedRuleDefault(
name=base.IDENTITY % 'create_user',
scope_type=['system', 'project'],
check_str=base.RULE_ADMIN_REQUIRED,
description='Create a user.',
operations=[
{'method': 'POST',
'path': '/v3/users'}
]
)
策略的 scope_type 属性可以在示例策略文件中使用现有的 description 生成，这使得它对需要理解策略的部署人员来说更加有用。 它也可以在操作的策略执行期间运行时可用。 这使得 oslo.policy 执行更容易确保执行的操作与令牌的授权上下文的范围匹配。 例如，将策略操作的 scope_type 与令牌范围上的角色进行比较，应该有助于解决 OpenStack 中的 admin-ness 问题。
备选方案¶
我们可以在项目之外记录操作的范围，但通过在代码中进行策略注册来执行它，可以减少出错的可能性。
Impact on Existing APIs¶
这将使 DocumentedRuleDefault 对象在记录和评估策略方面更有用。 此处描述的更改仅为附加的，不应影响该对象的现有功能。
安全影响¶
直接来说，这没有安全影响。 在未来，在项目开始使用该属性来评估策略后，安全性将得到提高。 有关详细信息，请参阅先前链接的 身份规范。
性能影响¶
无。
Configuration Impact¶
无。
开发人员影响¶
无。
Testing Impact¶
我们应该测试范围是否实际通告并在策略上设置。 我们还应该与 Patrole 团队 合作，看看这如何改进 OpenStack 中 RBAC 的测试。
实现¶
负责人¶
- 主要负责人
Lance Bragstad <lbragstad@gmail.com> lbragstad
里程碑¶
完成目标里程碑：queens-1
在 Queens 版本的早期提供此功能将允许项目通过自动文档提供范围文档。
工作项¶
扩展
DocumentedRuleDefault对象以支持scope属性
文档影响¶
此功能需要大量的文档和使用指南，描述它如何改进策略文档和评估。
依赖项¶
项目必须将策略移动到代码中并记录它，然后才能将范围与特定策略关联。 Keystone 还需要提供一种方法让用户获取系统范围的令牌。 之后，项目可以开始通过将其与令牌范围进行比较来强制执行策略范围，但大部分将由 oslo.policy 的 Enforcer 对象自动处理。
参考资料¶
无。
注意
本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode
