安全的 RBAC

建议阅读

说策略执行是一个复杂的主题可能是一种保守的说法。它需要操作环境来制定自定义策略以满足通用需求。 这也是 Secure RBAC 工作启动的原因之一，旨在为大多数需要更高粒度控制的用户提供一致性和“良好”的起点。

也就是说，任何致力于实施这些策略定制的人都可能受益于查阅一些参考资料，以期了解上下文。

历史背景 - 我们如何达到我们的访问模型

Ironic 的访问模型是通过 API 和存储的数据的演变而达到的。 随着存储的数据，基于存储在这些字段中的数据执行策略。

系统范围

系统范围的身份验证旨在用于“管理”活动，例如跨租户/项目，因为所有租户/项目都应可见于 Ironic 中的 `system` 范围的用户。

系统范围的请求没有与 Keystone 请求授权令牌关联的 `project_id` 值，该令牌用于与 Ironic 通信。 这些请求通过 keystonemiddleware 转换为值，这些值告诉 Ironic 该怎么做。 或者更准确地说，告诉策略执行框架做出决策所需的信息。

系统范围的请求与 Ironic 在 Secure RBAC 工作之前的访问控制非常一致。 原始自定义角色 `baremetal_admin` 的权限与系统范围的 `admin` 的权限相同。 同样，`baremetal_observer` 与系统范围的 `reader` 相同。 在这些概念中，`admin` 允许创建/删除对象/项目。 `reader` 允许读取项目详细信息，适用于可能需要具有只读访问权限或一线支持用途的帐户的用户。

除了这些概念之外，Secure RBAC 使用模型中还存在 `member` 角色。 Ironic 支持此角色，并且通常在系统范围内，`member` 角色用户能够执行基本的更新/更改，但特殊字段除外，例如禁用清理的字段。

项目范围

项目范围的身份验证是指请求令牌和关联记录指示关联的 `project_id` 值。

自引入基本功能以来，Secure RBAC 模型已扩展为 OpenStack 社区目标的一部分，包括在项目范围内包含 `manager` 角色。 默认情况下，此访问权限等效于项目范围的 `admin` 用户，但随着时间的推移可能会进一步明确。

遗留行为

API 服务的遗留行为是所有请求都被视为项目范围的请求，其中访问权限使用“管理项目”进行管理。 此行为已弃用。 新行为是通过 `system` 范围和 `project` 范围的请求来区分访问权限。

本质上，以前充当“管理项目”的角色，现在是 `system` 范围的使用。

以前，Ironic API 默认情况下会根据管理项目和关联角色响应访问被拒绝或被允许。 如果项目不正确或用户角色，这些响应将生成 HTTP 403。

注意

虽然 Ironic 具有 `owner` 和 `lessee` 的概念，但默认情况下不使用它们。 它们需要自定义策略配置文件才能在遗留操作模式中使用。

支持的端点

  • /nodes

  • /nodes/<uuid>/ports

  • /nodes/<uuid>/portgroups

  • /nodes/<uuid>/volume/connectors

  • /nodes/<uuid>/volume/targets

  • /nodes/<uuid>/allocation

  • /ports

  • /portgroups

  • /volume/connectors

  • /volume/targets

  • /allocations

项目范围的工作方式

Ironic 有两种项目使用模型，其中访问权限通常更委派给 `owner`，而对 `lessee` 的访问权限通常更实用。

所有者的目的是更多地使系统操作员能够将节点的许多管理活动委派给所有者。 这可能是因为他们物理上拥有硬件，或者他们负责该节点。 无论字段和机制支持的使用模型如何，这些字段都是为了支持人类，以及适用的服务。

租户的目的是更多地让租户在他们的项目中能够访问执行基本操作。 在某些情况下，这可能是为了重新配置或重建节点。 最终，这是租户的特权，但默认情况下，在项目范围内存在无法执行的操作和字段更新。

这些策略应用于查看数据的方式以及可以更新数据的方式。 通常，无法查看节点是项目 ID 对于所有者/租户而言是否正确造成的访问权限问题。

Ironic 项目试图普遍地规范我们认为合理的行为，但是操作员可能希望覆盖这些策略设置。 有关常规策略设置详细信息，请参阅 策略。

字段值可见性限制

默认情况下，Ironic 的 API 具有过滤节点值的概念，以防止敏感数据泄露。 系统范围的用户受到基本限制，而项目范围的用户默认情况下会受到进一步的策略检查。 此阈值由 `baremetal:node:get:filter_threshold` 控制。

默认情况下，以下字段在节点上被屏蔽，并受关联策略控制。 默认情况下，所有者能够深入了解基础设施，而租户用户默认情况下无法查看这些字段。

  • last_error - baremetal:node:get:last_error

  • reservation - baremetal:node:get:reservation

  • driver_internal_info - baremetal:node:get:driver_internal_info

  • driver_info - baremetal:node:get:driver_info

字段更新限制

此列表中的某些字段仅限于系统范围的用户，甚至仅限于系统管理员。 其中一些默认限制可能很明显。 所有者无法更改所有者。 租户无法更改所有者。

  • driver_info - baremetal:node:update:driver_info

  • properties - baremetal:node:update:properties

  • chassis_uuid - baremetal:node:update:chassis_uuid

  • instance_uuid - baremetal:node:update:instance_uuid

  • lessee - baremetal:node:update:lessee

  • owner - baremetal:node:update:owner

  • driver - baremetal:node:update:driver_interfaces

  • *_interface - baremetal:node:update:driver_interfaces

  • network_data - baremetal:node:update:network_data

  • conductor_group - baremetal:node:update:conductor_group

  • name - baremetal:node:update:name

  • retired - baremetal:node:update:driver_info

  • retired_reason - baremetal:node:update:retired

警告

`chassis_uuid` 字段是只写一次的字段。 因此，它仅限于系统范围的管理员。

有关这些字段的更多信息，请参阅 策略。

分配

API 的 `allocations` 端点与 API 的其他端点略有不同，因为它允许管理员分配物理机器。 在这种情况下，没有 `owner` 或 `project_id` 可用于控制创建过程的访问权限，任何项目成员都有权请求分配。 也就是说，他们的分配请求需要将物理节点拥有或租赁给 `project_id` 通过 `node` 字段 `owner` 或 `lessee`。

默认情况下，覆盖所有者的权限仅限于系统范围的用户，如果是在 `project` 范围内提出的任何新的分配请求，并且指定了特定的所有者，则 `project_id` 将被记录为分配的所有者。

最终，`owner` 和 `lessee` 权利在分配方面存在操作行为差异。 使用标准访问权限，`lessee` 用户如果拥有未分配或部署的节点，则可以创建分配，但仅使用 `member` 角色，他们无法重新配置节点。 对于具有 `admin` 角色的项目范围用户，情况并非如此。

警告

直到将 `[oslo_policy]enforce_new_defaults` 设置为 `True` 使用 `baremetal:allocation:create_pre_rbac` 策略规则，分配端点的使用仅限于项目范围的交互。 这是为了防止端点滥用。 之后，所有项目范围的分配将自动填充所有者。 系统范围的请求不受此限制，操作员可以通过 `baremetal:allocation:create_restricted` 策略更改默认限制。

实际差异

大多数用户在实施 `system` 范围的身份验证后，如果他们的身份验证令牌正确地设置为 `system` 范围并具有适当的访问级别角色，则不应注意到任何差异。 对于使用 `baremetal` 项目或其他自定义项目通过自定义策略文件以及自定义角色名称（例如 `baremetal_admin`）的大多数用户，这将需要将用户更改为具有 `admin` 权限的 `system` 范围的用户。

API 消费者最明显的区别是 HTTP 403 访问代码现在主要是 HTTP 404 访问代码。 访问概念已从“用户是否广泛具有 API 访问权限？” 变为“用户是否具有对节点和特定资源的访问权限？”。

什么是所有者或租户？

`owner` 或 `lessee` 是已分配裸机资源的项目。 通常，这些应该是服务项目，而不是专门用于特定用户的项目。 这将有助于防止在项目需要因个人离职而被删除时，`system` 范围的管理员不得不纠正所有权记录。

底层的 `project_id` 用于表示和关联所有者或租户。

如何分配所有者？

# baremetal node set --owner <project_id> <node>

注意

使用默认访问策略，`owner` 能够更改节点的分配 `lessee`。 但是 `lessee` 无法这样做。

如何分配租户？

# baremetal node set --lessee <project_id> <node>

Ironic 默认情况下会自动管理租户（lessee）在部署时，在节点部署时设置 lessee 字段，并在节点开始清理之前将其取消设置。

操作员可以通过 conductor.automatic_lessee_source 配置来定制或禁用此行为。

如果 conductor.automatic_lessee_source 设置为 instance（默认值），则它使用 node.instance_info['project_id']，该值在 OpenStack Nova 部署实例时设置。

如果 conductor.automatic_lessee_source 设置为 request，则 lessee 设置为请求上下文中 project_id – 这对于仍然使用 OpenStack Keystone 的独立 Ironic 部署非常理想。

如果 conductor.automatic_lessee_source 设置为 none，Ironic 将不会在部署时设置 lessee。

所有者（owner）和租户（lessee）之间有什么区别？

这在 项目范围的工作方式 中有很大一部分内容介绍，尽管如注释所示，它主要涉及访问权限。 lessee 的限制远比 owner 严格，并且 owner 可以撤销对 lessee 的访问权限。

对底层裸机节点的访问权限在 owner 和 lessee 之间不是排他的，并且此使用模型期望相关方之间进行一定程度的通信。

作为项目管理员，我可以创建一个节点吗？

从 API 版本 1.80 开始，添加了允许具有 admin 角色的用户能够在 Ironic 中创建和删除自己的节点的功能。

默认情况下启用此功能，并自动赋予创建的裸机节点 owner 权限。

可以通过将 api.project_admin_can_manage_own_nodes 设置为 False 来禁用此功能。

我可以使用服务角色吗？

在 Ironic 的较新版本中，添加了 service 角色，以实现帐户和对 Ironic API 的访问的分隔。 由于 Ironic 的 API 最初主要设计为“admin”API 服务，因此服务角色能够提供与具有 admin 或 manager 角色的项目范围用户相似的访问级别。

在访问权限方面，这最好被视为具有 manager 角色的用户，但权限略有提升，以便通过服务帐户使用该服务。

具有 service 角色的项目范围用户能够创建裸机节点，但无法删除它们。 要禁用创建节点的能力，请将 api.project_admin_can_manage_own_nodes 设置为 False。 在项目范围内可以访问/管理的节点也与 owner 和 lessee 访问模型一致，因此，如果节点不匹配用户的 project_id，那么 Ironic 的 API 将不会显示任何已注册的裸机节点。

在系统范围内，具有 service 角色的用户能够创建裸机节点，但同样，也无法删除它们。 访问权限建模为需要具有 admin 范围才能从 Ironic 中删除裸机节点。