系统范围基于角色的访问控制¶
规范范围：OpenStack 集成
https://storyboard.openstack.org/#!/story/2008425
Ironic 长期以来被认为是一个“仅管理员”服务。随着最近的贡献，Ironic 能够提供 多租户能力，这一情况发生了变化。这项工作是为了支持 Mass Open Cloud 社区 的努力，通过 owner 和 lessee 字段来划分访问和资源分配。
然而，人们越来越希望划分用户帐户可以访问 API 的范围。OpenStack 社区有时将这项工作称为“安全 RBAC”，这是一项在 OpenStack 服务中实现范围受限身份验证的举措，其中范围和建模保持一致，以提供一致的“授权体验”。这是通过 系统范围角色 分配来实现的。在这种模型中，存在 admin、member 和 reader。 admin 角色意味着 member，而 member 意味着 reader。这些角色存在于三种范围之一：system、domain 和 project。对于 OpenStack 中的大多数服务，相关的范围是 system 和 project 范围。
本质上，这项工作是将访问和操作分组到角色背后，这些角色是可以通过 keystone.users 中的角色分配应用于用户的角色和范围的组合，然后确保调用的访问权限不会允许不适当的访问，例如仅作为系统范围的只读角色编辑字段。从高层来看，这在概念上建模为 admin、member 和 reader 角色。在 代码中的策略 努力中，admin 角色被建模为 baremetal_admin 角色，而 reader 角色通过 baremetal_observer 角色建模，但是这些都不是系统范围的。现有的访问角色是项目范围的，范围限定于 baremetal 项目，并且 Ironic 没有令牌范围的概念。
角色定义
- admin - 这本质上是在操作环境中具有管理权限的用户
范围。这些帐户可以创建/删除 $things，并且在 keystone 默认配置中，此角色意味着
member角色。在 Ironic 的上下文中，我们可以将此用户视为将他们的裸机添加到 Ironic 的基础设施管理员。
- member - 这是可以对事物采取行动的用户。他们可能能够读取
并在对象中写入，但除非明确允许的操作，否则不能创建/删除新对象。Ironic 的一个例子可能是，我们可能希望允许成员能够请求分配，或更改节点的置备状态。类似于
admin意味着member，member意味着reader。
- reader - 这是需要能够具有只读访问权限的用户。
他们可以读取对象但不能更改、修改或删除对象。在
system范围中，这可能是网络运营中心员工，他们有业务需求能够观察状态和详细信息。在project范围中，这可能是试图核算资源或用于自动化流程/报告的人员。
注意
有关默认角色定义的更多详细信息，请参阅 Keystone 规范“定义默认角色” 或 Keystone 管理员指南。
注意
未来的可能性是可能存在一个 auditor 角色，但它将不匹配读者。审计员将是只读的，但他们的角色可能会允许解掩敏感值。尚未决定这一点，并且根据服务配置，很可能可以通过自定义策略文件手动实现。话虽如此，这目前不在本规范文件的范围内。同样重要的是要注意，admin、member 和 reader 角色不会自动解掩敏感数据，并且默认情况下不应期望这样做。
在考虑上述角色定义和裸机用例时，范围差异将对现有内容和未来内容产生重大影响。从高层来看，您不会允许项目范围的 admin 具有对 Ironic 的完全管理访问权限。
范围定义
system - 这类似于当今云部署的现有范围。
- domain - 此范围目前仅在 Keystone 中用于关联。
我们不期望它适用，并且 Ironic 中不存在基本要素。
- project - 这是用户是项目成员的逻辑分组
并在该项目中具有一定程度的隐含成员权利。这使用
project_id值进行跟踪和关联。
有关更多信息，请参阅 Keystone 管理 - 令牌 文档和 Keystone 贡献者 - 服务 文档。
问题描述¶
目前存在的基本问题是 Ironic 不理解范围访问。缺乏对范围访问的理解，加上现有的项目范围角色/访问，会造成混乱且与已实现能够具有范围划分访问权限的其他服务（例如，撰写本规范时的 Keystone 和 Nova）不同的身份验证体验。
巧合的是，更大的 OpenStack 运营商希望能够划分访问权限。换句话说，允许操作中心能够查看状态，但不能对节点采取行动。这可能是项目范围内的 reader 用户，或者在整个系统范围内。
随着 OpenStack 中的项目实施范围和角色划分，并启用基于范围的访问限制，Ironic 将与试图表示的模型不兼容的风险存在。
因此，我们必须实施支持以划分范围、角色，最终可能是一些远程资源的不同的访问模型。特别是，现有集成存在风险，因为它们可能会增长到仅期望项目范围的请求，并拒绝系统范围的成员请求。这些问题需要识别并适当处理。
总而言之，本规范的目的是对 ironic 和 ironic-inspector 进行更改，使其与 OpenStack 社区的其余部分保持一致且面向未来。这将进一步使基础设施运营商能够利用 OpenStack 社区中先前的社区策略工作来覆盖社区达成的策略默认值。
提议的变更¶
从高层来看，期望是
通过采用标准角色实现更大的 consistency。
实施能够迁移到标准基于范围的限制，新标准化的角色将适用。
将服务（例如 ironic）从
admin projects的概念迁移到system scope。
我们将通过以下方式做到这一点
构建一组新的策略，以反映安全的 RBAC 模型，其中“范围”包含在定义中。
弃用以前的代码中的策略，这些策略由范围限定于
baremetal项目的角色组成。预计这些将在稍后时间点被删除。实施显式测试，以确保按预期处理范围。
创建一个集成测试作业，利用
oslo.policy设置来强制范围限制，以帮助确保跨服务兼容性，并可能需要更改一些跨服务交互以确保请求被适当地建模。预计这可能会显示任何需要解决的潜在问题。
在弃用期间，运营商将继续能够利用以前的身份验证模型。
这些新策略将对我们现有的使用和数据模型进行建模，但应用范围和启用多租户访问。这将启用一个“友好”的默认使用路径，除非节点上的 owner 或 lessee 字段被填充，否则该路径将是可选的。
将三个定义的角色 admin、member 和 reader 与三个范围 system、domain 和 project 组合在一起，将产生可能性矩阵。但是，预计不需要 domain，从而留下六种访问场景或角色需要考虑。
请参阅 高层矩阵 以获取对预期使用模型的概述。
为了拥有一个一致的使用模式，现有的角色定义 baremetal_admin 和 baremetal_reader 将被弃用并删除，但是它们在设置 [oslo_policy]enforce_scope 和 [oslo_policy]enforce_new_defaults 参数为 True 后将不再有效。
除了新的策略定义之外，还需要在 ironic 和 ironic-inspector 项目中创建额外的测试，以验证基于范围的适当资源拒绝或强制执行。
可能需要应用额外的 issue 和权利验证逻辑，但是这可能需要相邻/集成的项目更改其策略执行。
注意
相邻/集成的项目/服务，例如 Nova、Neutron、Cinder、Glance、Swift 和 Ironic 之间的交互。服务代表原始请求者一段时间内传递上下文，并可以根据此上下文做出访问控制决策。Ironic 之前不得不解决 Neutron 和 Cinder 集成中的这些问题。
在 ironic-inspector 及其 API 方面，这项工作的默认策略将完全是系统范围的，并且预计不需要实施其他范围，因为 ironic-inspector 纯粹是一个仅管理员和硬件数据收集服务。
注意
在审查此规范文档时，有强调指出租户可能会觉得有必要能够触发对节点的检查，并使其报告到他们自己的ironic-inspector实例。这是一个有趣的可能性，但将是一个与本次工作范围不同的独立功能。之前“代码中的策略”工作的优势在于，如果操作上在操作员的安全姿态中允许，操作员应该能够简单地更新策略。
高级矩阵¶
下表使用了两个定义，这些定义源自 ironic 中现有的多租户工作。它们不是提议的新名称，而是用于提供对策略规则对齐代表的含义的概念理解，因为从技术上讲，基于变化和最终社区达成的协议，存在几种不同的访问矩阵。最终名称定义可能类似，但这是一种实现命名决策，而不是更高级别的设计决策。
is_node_owner- 当 API 消费者的项目 ID 值填充在Ironic 节点对象的
owner字段中时。这代表他们是裸机节点的权威所有者。
is_node_lessee- 当 API 消费者的项目 ID 值填充在Ironic 节点对象的
lessee字段中时。这被认为是节点当前或分配的用户。有关更多详细信息，请参阅允许可租赁节点规范。
角色 |
系统范围 |
项目范围 |
admin |
实际上与现有的“baremetal_admin”角色相同。 |
项目 |
member |
一个新的概念，用于一个执行者用户或 服务帐户。 不能添加或删除节点，但可以执行诸如 provision_state 更改之类的操作。 |
如果匹配 |
reader |
实际上与现有的“baremetal_observer”相同 |
这是一个只读用户概念，如果 |
注意
在此工作中没有提出 auditor 角色，但从长远来看确实有意义，并且应该从逻辑上考虑读者不等于审计员的角色。 auditor 的概念预计将允许取消屏蔽诸如屏蔽字段之类的机密信息。
注意
在讨论和交流中，某些角色/范围组合可能会以 {scope}-{role} 格式组合。这实际上是正在定义的角色。例如，system-admin 用于系统范围，或 project-admin 用于是项目管理员的用户。
注意
字段限制可能由额外的策略规则控制，这些规则可能以级联结构存在，如果未授予完全的通用更新访问权限，则应枚举较低级别的策略。
实际上，如果规则中定义了 PROJECT_ADMIN，它将匹配 project_id 与 owner 匹配并且用户具有管理员角色。 PROJECT_MEMBER 包含 PROJECT_ADMIN 或 project_id 与 lessee 匹配并且角色是 member。
备选方案¶
没有可用的替代方案作为实现模型。这是因为它试图符合整体 OpenStack 模型。细微的细节应该在实现中讨论。
数据模型影响¶
无
状态机影响¶
无
REST API 影响¶
此更改的整体高级行为将通过 oslo_policy 设置强制执行，直到从 Ironic 中删除过时的策略。
根据 API 标准，即使它不会修改功能行为，此更改将增加 API 微版本。这是为了使 API 消费者能够在升级时围绕可能的逻辑或策略更改进行导航。这与无法通过 API 表面可见的策略执行细节无关。
预计最终 API 用户行为不会发生变化，但是使用在 oslo.policy 中设置的范围强制执行，将需要适当范围的用户。
系统范围¶
系统范围角色的过渡相当简单，如 高级矩阵 中 提议的更改 中描述的图表所示。现有的 Admin/Observer 角色将被转换为 System-Admin 和 System-Reader。
此范围的补充是 member 角色概念。这是一个可以读取和更新但不能创建或删除记录的用户。换句话说，API 消费者可以部署节点，他们可以更新节点，但他们无法删除节点。他们应该能够附加/分离 VIF，并且最终这应该能够授予用于 nova-compute 进程的服务帐户的权利。
具有系统范围的任何有效角色类型的用户预计都应具有完整的 API 表面可见性，但特殊用途的 /v1/lookup 和 /v1/heartbeat 端点除外。这将与基于 项目范围 访问不同的，在项目范围内，只有在填充 owner 或 lessee 时才能看到节点。
待办事项
跟进 neutron 关于端口附加/分离的问题。
待办事项
跟进 Cinder 关于卷附加/分离的问题。
待办事项
跟进 Nova 关于通过上下文传递的权利的问题。
注意
此规范的主要重点是 Wallaby 开发周期，其中系统范围最有利于支持。考虑到时间限制和跨项目机制，随着时间的推移，我们可能会看到更多的工作来完善范围交互在此规范下进行。其中一些事情可能与 volume 或 port 附件有关，或者甚至可能是在 nova-compute 中更紧密地集成此功能。所有这些事情都会随着时间的推移而演变，在我们达到那个时间点之前，我们无法回答它们。
项目范围¶
项目范围的限制在安全的 RBAC 模型中差异很大，但是已经存在先例，即添加 is_node_owner 和 is_node_lessee 逻辑，这些逻辑将适用于项目范围的交互。
寻求 GET 项目范围资源的 API 消费者只能查看与 owner 和 lessee 字段关联的 is_node_owner 和/或 is_node_lessee 匹配的资源。
注意
节点可以独立地同时拥有 owner 和/或 lessee，并且目前策略模型分别区分访问权限。
在这种情况下，项目管理员将拥有与 System-Member 类似的权利，他们将能够更新硬件相关的字段，例如 driver_info，但前提是 is_node_owner 匹配。匹配 is_node_lessee 的项目管理员不应被允许更新诸如 driver_info 之类的字段。
待办事项
我们可能希望评估是否允许项目管理员更新 driver_info 是否有用。Dtantsur 认为，并且我同意，这很可能高度依赖于部署和操作，并且我们可能需要一个控制此行为的旋钮。
项目成员将再次限定为适用于其用户范围的适当数据库条目。他们应该能够更新诸如 instance_info 之类的字段，以及配置、取消配置和潜在地更新 VIF。
将需要一些额外的代码来执行访问权限验证，以确保项目成员正在尝试绑定到与他们的节点所有权和用户条目匹配的 VIF，或者 lessee 字段的值和请求用户的项目。
由于资产的物理性质，项目范围的用户无法创建或删除任何记录。
项目范围的读者，同样只会拥有与关联的 is_node_lessee 或 is_node_owner 相关的有限字段视图。
端点访问权限¶
此列表基于Baremetal API 参考中发布的的信息。此列表未涵盖节点对象上的所有操作。适用某些字段限制。有关节点的详细信息，请参阅 节点对象字段限制。
注意
此列表当前不包含节点上的所有可能操作。
端点 |
项目范围可访问 |
/ |
是，公共端点 |
/v1 |
是，公共端点 |
/v1/nodes |
过滤视图和访问权限，需要添加额外的策略规则。 |
/v1/nodes/{uuid} |
过滤视图和访问权限 |
/v1/nodes/{uuid}/vendor_passthru |
否，不允许，因为这是一个开放式的供应商机制接口。 |
/v1/nodes/{uuid}/traits |
是，可供 |
/v1/nodes/{uuid}/vifs |
是，写入访问需要额外的验证。 |
/v1/portgroups |
是，过滤视图和只读权限，用于 |
/v1/nodes/{uuid}/portgroups |
过滤视图和只读权限 |
/v1/ports |
是，过滤视图和访问权限，用于 |
/v1/nodes/{uuid}/ports |
过滤视图和访问权限。 |
/v1/volume/connectors |
是，过滤视图，只读。 |
/v1/volume/target |
过滤视图，需要额外的验证以防止请求的目标对用户/项目有效。 |
/v1/nodes/{uuid}/volume/connectors |
过滤视图，只读。 |
/v1/nodes/{uuid}/volume/targets |
过滤视图，只读。 |
/v1/drivers |
否，仅 |
/v1/nodes/{uuid}/bios |
是，基于对底层节点的访问权限的过滤视图。 |
/v1/conductors |
否，仅 |
/v1/allocations |
项目范围，但是访问模型面向使用此端点的所有者。 |
/v1/deploy_templates |
否，目前仅 |
/v1/chassis |
否，仅 |
/v1/lookup |
否，代理保留的端点。 |
/v1/heartbeat |
否，代理保留的端点。 |
警告
端口支持需要删除通过 port.extra['vif_port_id'] 的旧版 neutron 端口附件。
注意
贡献者一致认为 port 对象不需要项目范围的访问权限，但是一个重要的事项是，owner 可以被视为物理节点的最终 manager，并且 system 或 ironic 本身只是提供管理基础设施。这是一个有效的情况，因此我们有理由允许所有者比项目范围内的节点 lessee 拥有更多的访问权限。
注意
贡献者一致认为资源类和特征记录可能只需要 system 范围的用户编辑，但是也可以认为应该能够将此委托给 owner。此规范本身并没有要求特定的模式，而更多的是预计这将是一个需要在实施中解决的实现细节。它可能从只有具有适当角色的 system 范围的用户可以编辑开始，并且可能会演变，或者可能不需要。
节点对象字段限制¶
注意
这些是提议的，但不是最终的。功能的实施将决定最终的字段行为和访问权限。
uuid - 只读
name - 如果项目拥有物理机器，则项目管理员可读/写。
power_state - 只读
target_power_state - 只读
provision_state - 只读
target_provision_state - 只读
maintenance - 可读/写
maintenance_reason - 可读/写
fault - 可读/写
last_error - ??? .. TODO::
last_error的问题在于，它可能会泄露导体、bmc 等基础设施主机名。对于 BMaaS，这可能是有意义的？reservation - 作为 True/False 返回给项目用户。
driver - 只读
driver_info - 可能会返回一个空字典，或者我们可以删除 URL，但这似乎更复杂。
driver_internal_info - 很有可能返回一个空字典，因为项目管理员和项目成员实际上不需要查看驱动程序的内部工作细节。
properties - 只读
instance_info - 项目管理员/项目成员 读写
instance_uuid - 项目管理员/项目成员 读写
chassis_uuid - 返回 None
extra - 项目管理员/项目成员 读写 .. TODO:: 另一个移除旧 vif 处理逻辑的原因是 extra 字段。
console_enabled - 项目管理员/项目成员 读写
raid_config - 只读
target_raid_config - 只读
clean_step - 只读
deploy_step - 只读
links - 只读
ports - 只读
portgroups - 只读
resource_class - 只读
boot_interface - 只读
console_interface - 只读
deploy_interface - 只读
inspect_interface - 只读
management_interface - 只读
network_interface - 只读
power_interface - 只读
raid_interface - 只读
rescue_interface - 只读
storage_interface - 只读
traits - 只读
vendor_interface - 只读
conductor_group - 返回 None/只读
protected - 读写
protected_reason - 读写
owner - 只读，且租户可以查看所有者 ID。
lessee - 项目管理员/项目成员 读写。租户将被禁止更改该字段的值。
description - 读写
conductor - 返回 None，因为它提供了对正在运行的基础设施配置和状态的洞察力，即只有系统可见的状态才是适当的。
allocation_uuid - 只读
特殊区域
- volume - 这代表卷目标和连接器。所有值
通过此路径可见的都应该是只读的。连接器逻辑应该对项目管理员或项目成员在适用情况下可读/写，但是需要在底层存在额外的逻辑检查来验证项目和用户的权限访问。
- state - 这是更改状态、指示器、
配置等的入口路径。如果它映射到关联的所有者或租户字段，则应允许项目管理员或项目成员执行此操作。
- vendor_passthru - 供应商直通将不可用于项目
在 RBAC 模型中的作用域用户。
注意
所有被清除的字段，即设置为 None 或 {} 的字段，预计都将是新 RBAC 模型中作用域帐户的只读字段。
客户端 (CLI) 影响¶
“openstack baremetal” CLI¶
预计没有。
“openstacksdk”¶
预计没有。
RPC API 影响¶
目前，预计对 RPC API 没有影响。也就是说，鉴于安全更改的性质，如果需要额外的参数，则可能需要进行一些更改。现有的模式已经存在于此，并且任何此类更改都将通过现有的 rpc 版本最大值和固定功能进行处理。
驱动程序 API 影响¶
无。
Nova 驱动程序影响¶
我们可能希望继续建立 nova 在节点 lessee 字段中存储用户项目 ID 的能力。在新的使用模型中，这将允许更“自然”的使用模式，并允许用户能够利用电源操作或重新启动甚至可能重新构建其已部署的实例等功能。
待办事项
我们应该进一步讨论这个问题。它可能只是 Ironic virt 驱动程序中的 nova-compute 的一个旋钮。
Ramdisk 影响¶
预计没有，因为 API 现有的心跳和查找资源不会被修改。
安全影响¶
Secure RBAC 工作总体目标是启用并允许操作员能够在更严格和受约束的模型中运行服务，角色之间存在更大的区分。
从某种意义上说，系统范围的操作模式最终将成为正常操作模式。这是为了鼓励更安全的环境，但是这完全取决于默认策略和操作员制定的可能覆盖默认策略的策略。此规范的总体目标也是帮助识别新的策略机制。
为了帮助管理这一点并确保按预期执行整体行为，我们预计需要创建 API 行为测试，以确保操作安全并验证未来的代码更改不会对权限执行产生不利影响。
其他最终用户影响¶
预计没有直接的最终用户影响。
可扩展性影响¶
无。
性能影响¶
预计没有直接的性能影响。对象模型已经将列表过滤推送到 DBAPI 级别，这对于整体性能处理来说是理想的。一些额外的检查可能会产生轻微的开销，但总体而言，它应该很小，并且仅限于 API 服务中的逻辑。
其他部署者影响¶
预计云基础设施操作员可能需要调整 oslo_policy 设置以启用或禁用这些新策略。这可能包括云操作员继续使用较旧或更严格的策略来提高操作安全性。
开发人员影响¶
目前预计没有。
实现¶
负责人¶
- 主要负责人
Julia Kreger (TheJulia) <juliaashleykreger@gmail.com>
- 其他贡献者
Steve Baker (stevebaker) <sbaker@redhat.com>
工作项¶
创建表示当前交互模型的正/负策略检查测试。
创建作用域策略定义和相关的正/负行为测试
为 System-Admin 创建/迁移，其中“admin”测试适当强制执行与以前的测试相同的连续性。
为 System-Reader 创建/迁移，其中值可见但无法写入。
为 System-Member 创建类似测试
为 Project-Admin 创建类似测试
为 Project-Member 创建类似测试
为 Project-Reader 创建类似测试
实现一个 CI 作业，该作业运行一个完整的集成序列并启用作用域策略执行，通过
[oslo_policy]配置。文档！
阶段¶
部署的初始阶段是现有项目管理员作用域身份验证的系统范围使用的等效阶段。
下一个阶段，大概跨越一个主要版本，然后涵盖项目作用域访问权限和更改。
依赖项¶
需要更新 oslo_policy 的最低版本以匹配 Victoria 开发周期的工作产品，但是预计这将作为 JSON 到 YAML 策略迁移工作的一部分完成。
测试¶
预计会创建一个 CI 集成作业，或者利用一个已经使用最广泛集成组件的作业，以确保策略得到执行，并且这种执行适用于所有组件。由于此工作性质和范围，Ironic 可能是第一个设置作用域限制授权的项目，因为其他项目也在朝着这个方向努力。
升级和向后兼容性¶
不适用。
文档影响¶
需要发布发布说明，其中包含先前的策略弃用，以及更新主要文档以反映基于作用域的配置。根据更大的社区在 RBAC 策略工作和最终用户/操作员需求方面的决定，可能需要内联文档警告。
