允许节点所有者管理节点

https://storyboard.openstack.org/#!/story/2006506

本规范描述了一项更新，允许节点所有者通过 Ironic API 管理其节点，而无需管理整个节点集群。这是通过在 REST API 中暴露所有者节点数据以进行策略检查来实现的。

问题描述

Ironic 并非多租户；具有 API 访问权限的任何节点都有权访问所有节点。虽然节点具有 owner 字段，但它纯粹是信息性的，并且未与任何形式的访问控制相关联。

为 Ironic 带来完整的多租户支持将使我们能够解决以下用户故事

独立 Ironic

作为共享数据中心的用戶，我们希望使用 Ironic 来管理我们的硬件资源。每个工作组应该能够控制自己的资源，而无需访问其他组拥有的硬件资源。

数据中心运营商

作为共享数据中心的运营商，我希望使用 Ironic API 将裸机硬件的电源控制委托给硬件所有者。通过使用 Ironic API 而不是现有的嵌入式管理协议（例如 IPMI），我可以在保持共享管理网络简单性的同时，对谁可以访问哪些硬件进行精细控制。

提议的变更

Ironic API 已经有一种控制 REST API 访问权限的方法：一个策略引擎 [0]，该引擎贯穿整个 REST API。但是，当节点控制器使用策略引擎 [1] 时，它在不传递任何关于被检查节点的信息的情况下进行操作。其他服务，例如 Nova [2] 和 Barbican [3] 会传递额外的信息，我们建议这样做。总而言之，我们希望

  • 假设节点的 owner 字段设置为 Keystone 项目的 ID。我们将此项目称为“节点所有者”。

  • 更新节点控制器，以便策略检查也传递有关节点的信息，包括 owner 字段。

  • 更新 Ironic 的默认生成的策略文件，以包含一个 is_node_owner 规则

    • “is_node_owner”: “project_id:%(node.owner)s”

    策略文件的其余部分将保持不变，这意味着默认 API 访问权限不会发生变化。

  • 创建文档，解释如何更新 Ironic 策略文件以授予所有者 API 访问权限。例如

    • “baremetal:node:set_power_state”: “rule:is_admin or rule:is_node_owner”

    请注意，Nova 以类似的方式授予 API 访问权限 [4]。

此更新足以控制大多数 API 函数的访问权限 - 除了列表函数。对于那些函数，我们建议以下内容

  • 现在，策略规则 ‘baremetal:node:get’ 用于 get_all 和 get_one。我们可以添加两个新的策略规则：baremetal:node:list_all 用于检索所有节点，以及 baremetal:node:list 用于检索其 owner 字段与查询项目匹配的节点。

  • 更新 REST API 节点列表函数，首先对 baremetal:node:list_all 进行策略检查。如果通过，则返回所有节点；否则，我们对 baremetal:node:list 进行策略检查。如果通过，则返回根据请求上下文中指定的项目过滤的 owner 字段的节点。这些列表函数已经具有按 owner 过滤的选项 [5]。

  • 更新默认生成的策略文件，以将 baremetal:node:list_all 和 baremetal:node:list 设置为 rule:baremetal:node:get，以确保向后兼容性。

分配 API 变更

Allocation 对象表示查找和预留合适的节点的请求，因此应该对非管理员用户可用。为此，我们将为分配引入一个 owner 字段，并开始区分两种类型的分配

无限制分配

与以前一样工作。它们只能由管理员用户创建，并且可以设置任何 owner。创建它们受现有的策略 baremetal:allocation:create 管控。

受限分配

由非管理员用户创建，并且 owner 与创建用户的项目 ID 匹配。创建它们将受新的策略 baremetal:allocation:create_restricted 管控。

这两个策略将是互斥的，并且工作方式如下

  1. 首先，检查 baremetal:allocation:create。如果通过，则接受任何 owner 值。如果未提供 owner，则该字段保留为 None。

  2. 如果第一次检查未通过，则检查 baremetal:allocation:create_restricted。 owner 字段必须与用户的项目 ID 匹配或为空（在这种情况下，它设置为用户的项目 ID）。如果

    1. 无法确定用户的项目 ID（即，受限分配在独立模式下不起作用）。

    2. 请求的非空所有者与项目 ID 不匹配。

  3. 否则，创建分配失败。

最后，处理具有非空 owner 的分配时，仅考虑具有匹配 owner 的节点。

备选方案

一种替代方法是在数据库 API 级别执行这些检查。但是，这需要在大量单个函数上使用新的代码模式。

数据模型影响

无

状态机影响

无

REST API 影响

有关详细信息，请参阅上面的“提议的变更”。

客户端 (CLI) 影响

无

“ironic” CLI

无

“openstack baremetal” CLI

无

RPC API 影响

无

驱动程序 API 影响

无

Nova 驱动程序影响

无

Ramdisk 影响

无

安全影响

此更改允许将功能暴露给其他用户。但是，默认情况下会阻止此访问；它需要更新 Oslo 策略文件，并且可以由管理员根据需要进行调整。

其他最终用户影响

无

可扩展性影响

无

性能影响

无：虽然需要检索节点数据才能将其信息传递到策略检查中，但控制器函数已经检索了该信息。 [6]

其他部署者影响

无

开发人员影响

无

实现

负责人

主要负责人：* tzumainn - tzumainn@redhat.com * larsks - lars@redhat.com

其他贡献者：* dtantsur - dtantsur@redhat.com

工作项

  • 更新节点控制器。

  • 添加文档。

  • 编写测试。

依赖项

无

测试

我们将添加单元测试和 Tempest 测试。

升级和向后兼容性

使用 owner 字段用于项目 ID 的现有 Ironic 安装将受到最小的影响，原因有两个

  • 如果 owner 字段与项目 ID 不匹配（或为 None），则建议更新策略文件不会授予任何非管理员对 Ironic API 的访问权限。

  • 如果未更新策略文件，则此更改不会对最终用户产生影响。现有的安装可以选择不更新其策略文件。

文档影响

我们将包含额外的文档，描述使用 node_owner 策略角色的可能应用。

参考资料