代码中的策略¶
部署者目前需要维护策略文件，无论他们是否更改 Keystone 提供的默认策略。维护策略文件可能很繁琐且容易出错。此外，我们在发布过程中没有使用任何工具来生成或传达策略更改。通过将策略移入代码，我们可以利用工具使部署者的维护更容易，并转向更好的默认策略值。
问题描述¶
如今，策略存在于文件中，部署者需要在其部署中维护该文件。如果部署者需要更改操作的默认策略规则，他们必须进行这些更改并持续检查，以确保与策略文件的每个新版本之间的冲突得到解决。即使部署仅使用默认策略，维护起来也很麻烦。
提议的变更¶
建议的解决方案是将策略签入代码库，并使用 oslo.policy 库进行注册。这与项目使用 oslo.config 注册和使用配置选项的方式非常相似。如果磁盘上提供了策略文件中的策略，则将注册这些策略而不是代码中的默认策略。这为部署者提供了一种覆盖我们提供的默认值的方式。
注册需要两部分数据
操作，例如“identity:get_user”或“identity:update_project”
规则，例如“role:admin”或“rule:admin_or_owner”
还可以提供描述，这些描述有助于描述操作以及执行它所需的规则或角色。在从注册规则生成示例策略文件时，可以使用此描述。
这与 nova 将策略代码化的方法完全相同。
以下是该方法带来的好处
不再需要在树中维护策略文件。
我们可以提供一个工具来通知操作员策略发生更改或添加新策略时的情况。
我们可以提供一个工具来帮助减少策略文件中的冗余。
就像我们配置选项一样，更容易提供每个策略的描述。
备选方案¶
另一种方法是将策略拉入 Keystone 作为官方资源。这仍然需要某种策略覆盖能力，用于不希望部署默认策略的部署。
安全影响¶
没有，此更改只是更改了策略的定义位置，并允许在必要时覆盖它。
通知影响¶
无。
其他最终用户影响¶
没有。策略将继续像今天一样被评估和执行。
性能影响¶
将策略移入代码的性能影响应该很小。如果部署没有磁盘上的策略文件，则服务不必获取它。相反，默认值将从代码中注册和使用。如果部署正在使用策略覆盖，则两种方法的组合与代码中的默认值相比，可能会产生一些性能影响，但总体影响应该可以忽略不计。
其他部署者影响¶
如果部署者已经修改了默认策略文件，他们将不得不继续维护这些更改。对于修改策略条目子集或不修改的部署者，他们基本上可以删除策略文件，或者默认的策略。最终结果应该是一个策略文件，其中仅包含部署者希望强制执行的覆盖。
另一个部署者影响是，部署者不再需要通过手动检查发布中的策略文件来双重检查他们是否通过保护所有新操作。相反，他们可以收到有关发布中可用新策略的通知，然后选择接受文档化的默认值或选择覆盖。
开发人员影响¶
在将策略添加到代码之前，应先注册所有策略。虽然代码正在切换检查到 context.can()，但可以使用尚未注册的策略检查。在某个时候，应该添加一个黑客检查来禁止使用 oslo_policy.Enforcer.enforce()。还应添加检查和测试，以确保新的策略条目伴随着发布说明。
实现¶
负责人¶
- 主要负责人
Anthony Washington (antwash) Richard Avelar (ravelar)
- 其他贡献者
Lance Bragstad (lbragstad)
工作项¶
调查将 oslo.policy 添加到 Keystone 策略的过程。
找到挂钩并注册策略的位置。
逐步将策略检查从
policy.json移入 oslo.policy 对象。可以逐步完成此操作，并应从policy.json中删除检查。添加部署者文档。
从 devstack 中删除策略文件。
添加示例文件生成器，以写入合并的策略文件。这将是 Keystone 使用的有效策略，是默认值和配置覆盖的组合。
添加一个
keystone-manage命令，以转储策略文件中与编码默认值重复的策略列表。这将帮助部署者从现有策略文件中删除策略。
依赖项¶
没有，我们今天就可以开始这项工作了。
文档影响¶
将更新有关策略文件的文档，以说明仅需要包含与默认值不同的策略。
