动态策略

动态策略

改进 OpenStack 上的访问控制

每周会议

待定

---

背景

OpenStack 使用基于角色的访问控制 (RBAC) 机制来管理授权，它定义了用户根据分配给他们的角色是否能够对资源执行操作。资源包括虚拟机、卷、网络等，并组织到项目（project）中，这些项目由域（domain）拥有。用户在域或项目上分配角色。

用户获取域或项目范围的令牌，该令牌包含用户分配给他们的角色，并将此令牌与请求一起传递给服务以对资源执行操作。服务会检查令牌中的角色和范围，以及策略文件 policy.json 中针对请求操作定义的规则，以确定用户是否具有足够的权限。

---

演进

• 如何演进策略管理机制，当前使用一种非同步机制来更新 policy.json 文件？
• 如何改进委派机制，允许用户仅委派其角色的子集，这些子集可以针对每个域进行自定义？
• 如何提供更好的默认策略，修复管理员在任何地方都是所有地方管理员的错误？

---

路线图

故事 1 - 作为云管理员，我希望通过 API 管理策略

依赖于： 无

作为云管理员，我希望能够创建一个策略并将其绑定到基于其 URL 的端点，而我的 CMS 事先知道该 URL。除了能够修补、删除和显示整个策略之外，我还希望单独管理规则。

• 规范
  • 策略管理 API
    • 待办事项：创建规范
  • 将策略与端点 URL 关联
    • 按 URL 划分的策略
  • 策略存储后端
    • 策略规则从数据库管理
    • 用于管理策略数据库中属性层次结构的 API 规范
    • 用于管理数据库中策略规则的基本 API 规范
    • 策略映射 API

故事 2 - 作为云管理员，我希望使用我通过 API 定义的策略的服务

依赖于： 故事 1 - 作为云管理员，我希望通过 API 管理策略

作为云管理员，我希望我的服务端点使用我定义的并与之关联的策略（如果有）。中间件应从策略管理服务器下载最新的策略并根据其配置文件中的 endpoint_url 进行缓存。我的 CMS，知道该 URL 事先，会将此值放在中间件配置中。

• 规范
  • 从服务器获取 policy.json

故事 3 - 作为域管理员，我希望定义对我的业务有意义的角色

依赖于： 无

作为域管理员，例如代表客户，我希望定义一组对他们有意义的角色。作为全局角色，这些角色可以在分配中使用。

• 规范
  • 添加对特定于域的角色支持。（命名空间角色）

故事 4 - 作为管理员，我希望定义角色层次结构，允许只委派角色的子集

依赖于： 无

作为可以定义角色的管理员，我希望能够以层次结构的方式创建它们，这意味着拥有从另一个角色继承的角色意味着继承授权。

• 规范
  • 层次角色

故事 5 - 作为部署者，我希望拥有更好的默认策略，区分不同的管理员范围

依赖于： 故事 4 - 作为用户，我希望定义角色层次结构，允许只委派角色的子集

作为部署者，我希望定义针对云、域和项目管理员的不同角色的默认策略。解决长期存在的问题，即任何地方的管理员都是所有地方的管理员。此外，公共规则应在所有服务中保持一致。

• 规范
  • 改进默认策略
    • 待办事项：创建规范
  • 默认策略
  • 统一的策略文件

故事 6 - 作为开发人员，我希望在中间件和服务之间拆分策略执行

依赖于： 故事 2 - 作为云管理员，我希望使用我通过 API 定义的策略的服务

角色执行可以放在中间件中，而策略规则中包含的其他约束由服务执行。

• 规范
  • 从 keystonemiddleware 执行策略

---

工作流 - Liberty 范围

Liberty 目标任务

Liberty 周期中提出的内容是动态传递策略，即向 Keystone 服务器添加将策略信息分发到服务端点的能力。

总体方向是

1. 允许从 Keystone 基于端点 URL 获取策略文件
2. 修改 keystonemiddleware 以（在配置后）从 keystone 基于端点 URL 获取策略文件
3. 修改 oslo.policy 以支持将端点的库存策略与动态策略合并。默认合并策略将是“动态规则覆盖库存规则”。

此目标由以下核心规范表示

• “动态策略叠加”（https://review.openstack.org/#/c/196753/），指定 oslo.policy 库将如何将现有本地策略文件与动态上传的自定义规则叠加；
• “动态策略获取和缓存”（https://review.openstack.org/#/c/134655/），定义 Keystone 中间件将如何获取其正在服务的当前服务端点的策略，然后要求 oslo.policy 将现有本地策略文件叠加；
• “动态策略传递机制”（https://review.openstack.org/#/c/197980/），定义 Keystone 服务器将如何控制缓存机制，以确保不同服务端点之间的策略一致性，这些端点必须具有相同的策略，例如，在 HAProxy 后运行的多个 Nova 进程。

当前，围绕将动态策略与给定的服务端点关联存在一些讨论。替代方案在以下规范中提出

• “具有自定义 ID 的动态策略”（https://review.openstack.org/#/c/198000/），建议允许创建具有自定义 ID 的策略实体，从而简化 Keystone 中间件的配置并改善用户体验；
• “按 URL 划分的策略”（https://review.openstack.org/#/c/192422/），建议通过其 URL 识别服务端点，然后使用该 URL 将策略实体与它们关联。

工作流 1 - 初始安装策略

此工作流在下面的序列图中表示，定义了管理员安装 Nova 将如何导致上传策略文件。

工作流 2 - 自定义策略

此工作流在下面的序列图中表示，定义了管理员如何自定义策略。

工作流 3 - 用户请求 URL

此工作流在下面的序列图中表示，定义了如何将上述工作流联系在一起，从而在调用服务 API 时提供动态访问控制解决方案。