策略默认刷新

基于角色的访问控制 (RBAC) 策略在 OpenStack 中一直是运维人员关注和痛点所在。其实现复杂难懂，项目间不一致，且缺乏安全的默认设置。为了改进 OpenStack 现有的默认策略，Consistent_and_Secure_Default_Policies_Popup_Team 1 成立，以跟踪所有项目的策略刷新，其中 Keystone 是主导者。Keystone 定义了持续的策略目标和路线图、默认角色以及对系统范围和项目范围 RBAC 的重新阐明。作为这个 popup_team 的成员，Cyborg 也会跟进策略默认刷新。

问题描述

Cyborg 当前的默认策略不完整且不够好。由于 Cyborg V2 API 在 Train 中新实现，V2 API 的 RBAC 检查仍然不完整。现在 Cyborg 主要有三个策略规则

  • 允许

  • 仅管理员

  • 管理员或所有者

首先，“允许”意味着任何访问都会通过。现在“允许”规则被 cyborg:arq:create 使用，这太宽松了。我们达成一致 2，不应该向所有用户开放此权限。关于新规则，请参阅用例部分中介绍的 cyborg 策略表。

其次，“仅管理员”用于全局管理员，他们能够对 cyborg 进行几乎任何更改，并查看 cyborg 系统的所有详细信息。该规则实际上适用于具有管理员角色的任何用户，无论使用哪个项目，任何具有 admin 角色的用户都将获得此全局访问权限。

第三，“管理员或所有者”听起来像是检查用户是否是项目的成员。但是，对于大多数 API，我们使用默认目标，这意味着该规则将适用于任何经过身份验证的用户。

有了以上所有策略规则，仍然存在一些没有得到很好覆盖的情况。例如，在没有授予全局管理员角色的情况下，不可能允许用户从系统级别检索/更新由多个项目共享的设备。此外，Cyborg 现在没有“读者”角色。

Keystone 默认提供 member、admin 和 reader 角色。我们可以使用这些默认角色：https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html

此外，我们可以使用新的“系统范围”概念来定义哪些用户是系统管理员：https://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html

用例

Cyborg 默认配置应支持以下用户角色

  • 添加系统范围管理员：用于操作系统级资源

  • 添加系统范围读者：系统级资源的只读角色

  • 添加项目范围读者：项目级资源的只读角色

  • 默认将现有管理员刷新为项目范围管理员

  • 添加项目范围成员：项目级非管理员 API 的角色

Cyborg V2 API 需要 RBAC 检查。V2 API 的对象列在以下内容中

  • device_profile 3，作为加速器请求中的“flavor”，通常应该是一个系统级资源，尤其是在公有云中，其中计费基于 device_profile。因此我们达成一致 4，device_profile:create 和 delete 需要 sys_admin。对于其他特定的云，例如私有云提供商，如果他们希望其他用户创建 device_profiles，他们可以自行更改策略。

  • devices 和 deployables 5 对象用于描述硬件加速器，其中 device 指的是硬件，deployables 源自 device。device:update API 引入用于 sys_admin 启用或禁用特定设备，而 deployable:update API 为 project_admin 提供了一种更新 shell 镜像/FPGA bitstream 以自定义用户逻辑的方式，用于指定的 deployable。请注意，sys_admin 需要对设备进行预配置。

  • accelerator_requests 由 nova 发送，用于在实例启动期间将加速器绑定/解绑到 VM。任何能够创建 VM 的项目用户都应该能够创建 arq，因此 arq:create 需要“member”角色。对于 arq:patch 和 arq:delete，admin_or_owner 应该有意义。

为了清楚起见，所有 Cyborg V2 API 操作所需的角色定义在表 cyborg-policy-table 中。

在引入上述新的默认权限时，我们必须确保

  • 使用默认策略的运维人员至少有一个周期来向用户添加额外的角色（可能通过隐式角色）

  • 具有覆盖策略的运维人员至少有一个周期来了解新的默认设置可能对他们有何帮助或没有帮助

提议的变更

根据上述讨论，我们将尝试尽可能地减少更改以满足要求。对于当前阶段，应该至少进行以下更改。每个策略规则都将使用适当的 oslo.policy 的“scope_types”，在 cyborg 的情况下为“system”和“project”。我们将使用 DocumentedRuleDefault 来更新策略并遵循 oslo.policy 的弃用工作流程，在弃用期间同时激活旧的和新的策略检查字符串。

  • 添加系统范围管理员策略

    该策略对于需要系统级管理员操作设备（例如编程或固件升级）以及系统管理员需要执行服务禁用/启用等操作的情况非常有用。

  • 添加系统范围读者策略

    该策略对于需要更安全地访问由多个项目共享的设备时，需要只读角色的情况非常有用。

  • 添加项目范围读者策略

    类似地，该策略对于需要更安全地访问项目级别资源时，需要只读角色的情况非常有用。例如，某些用户应该仅具有检查和使用资源的权限，而不应更新资源。

  • 添加项目范围成员策略

    该策略将用于检查用户是否有资格发布非管理员 API，例如 arq 创建。

POC：https://review.opendev.org/#/c/699102/，https://review.opendev.org/#/c/700765/

备选方案

保留旧的策略机制，但一方面，随着越来越多的 api 功能添加，策略检查将变得更加复杂，另一方面，有一些重要的情况没有被旧的策略机制覆盖或很好地覆盖。这次刷新将使 cyborg 策略基本全面和干净。

数据模型影响

无

REST API 影响

应重新评估每个 API 的操作，并关联适当的范围或范围。

以下新角色将添加到 cyborg 默认配置中以替换旧策略，更多详细信息可以在上述 cyborg-policy-table 中找到

  • 项目读者检查

    • GET /v2/device_profiles

    • GET /v2/device_profiles/{device_profiles_uuid}

    • GET /v2/accelerator_requests

    • GET /v2/accelerator_requests/{accelerator_request_uuid}

  • 系统读者检查

    • GET /v2/devices

    • GET /v2/devices/{device_uuid}

  • 系统管理员检查

    • PATCH /v2/devices

    • POST /v2/device_profil

    • DELETE /v2/device_profiles/{device_profiles_uuid}

    • DELETE /v2/device_profiles?value={dev_profile_name1},{dev_profile_name2}

  • 项目管理员检查

    • PATCH /v2/deployables/{uuid}

  • 项目成员检查

    • POST /v2/accelerator_requests

    • PATCH /v2/accelerator_requests/{arq_uuid}

    • DELETE /v2/accelerator_requests?arqs={arq_uuid}

    • DELETE /v2/accelerator_requests?instance={instance_uuid}

注意

为了清楚起见，由于隐式角色，以下是等效的默认角色将由 Keystone 在引导过程中使用 implied roles 创建。如上所述，拥有 admin 角色意味着用户也具有与 member 角色相同的权利。因此，此用户也具有与 reader 角色相同的权利，因为 member 意味着 reader。

这保持了策略文件的清洁。例如，以下是由于隐式角色而等效的

“cyborg:device:get_all”: “role:reader OR role:member OR role:admin” “cyborg:device:get_all”: “role:reader”

隐式角色的链将与 policy-in-code defaults 以及 Keystone 文档更新一起记录，并说明这一点。

安全影响

策略默认刷新将有助于保持系统的安全性。

通知影响

无

其他最终用户影响

无

性能影响

无

其他部署者影响

部署人员需要查看新的策略（通过发布说明传达），以确保他们可以采用它们。

开发者影响

新的 API 必须添加遵循新模式的策略。

实现

负责人

主要负责人

<yumeng-bao>

工作项

为了确保每次发生更改时，现有的策略正常运行，我们将遵循 6 并按以下顺序提出更改

  • 将新角色添加到 cyborg 策略中，包括项目读者、项目成员、系统读者、系统管理员。

  • 更新使用上述新角色的 API 和单元测试。

  • 更新使用其他角色（例如项目管理员、管理员或用户等）的 API 和单元测试。

  • 重构 cyborg 策略文件。

依赖项

无

测试

应添加策略规则和 API 的测试。参考 keystone-tempest-plugin 中的 RBAC 测试：https://review.opendev.org/#/c/686305/

文档影响

API 参考应与任何策略更改保持一致，特别是关于默认读者角色。

参考资料

1

一致且安全的默认策略 Popup Team

2

用于 arq-create 的角色

3

设备配置文件定义

4

用于 device_profile 的角色

5

设备和 deployable 定义

6

策略迁移步骤

历史记录

可选部分，旨在每次更新规范时使用，以描述新的设计、API 或任何数据库模式更新。有助于让读者了解随着时间的推移发生了什么。

修订

发布名称

描述

Ussuri

引入

Victoria

重新提出