SRBAC: 实现项目角色支持

https://blueprints.launchpad.net/tacker/+spec/implement-project-personas

本文档讨论了在 Tacker 中实现项目角色。

基于角色的访问控制 (RBAC) 被大多数 OpenStack 服务用于控制用户对资源的访问。如果用户拥有执行操作所需的角色，则授予授权。

问题描述

在 Zed 周期中，OpenStack 技术委员会提议实现对项目角色的支持 [1]。

实现对项目角色的支持。这是为了引入成员和读者角色来操作其项目内的内容。默认情况下，任何其他项目角色（例如 foo）都将不允许在项目中执行任何操作。

遗留的管理员将保持不变，并继续以目前的方式工作。

在 OpenStack 中，现有的“owner”规则允许任何角色用户访问项目资源。例如，假设 role:foo 表现为项目资源的拥有者。

项目角色的实现将有助于限制任何角色用户访问项目资源，除了管理员、成员或读者。

在 Tacker 中，我们需要修复现有的“owner”规则，并实现新的规则作为 project-member 和 project-reader，以限制对项目拥有资源的访问。

提议的变更

OpenStack Keystone 已经支持隐式角色，这意味着分配一个角色意味着分配另一个角色。

新的默认角色 reader 和 member 也已添加到 bootstrap 中。如果重新运行 bootstrap 过程，并且 reader、member 或 admin 角色已经存在，则将创建一个角色暗示链：admin 暗示 member 暗示 reader。

这意味着如果在策略规则中设置类似 role:reader 的内容，则 role:admin 和 role:member 仍然可以访问该策略。

实现对 project-reader 的支持

project-reader 角色将在其自己的项目资源内运行，并在项目中具有只读访问权限。不允许对项目拥有资源进行任何可写更改。

project-reader 的更改将确保默认情况下，该项目中的任何其他角色（例如 foo）都将无法执行任何操作。

project-reader 由在项目上具有 reader 角色的用户表示。它旨在由最终用户用于项目内的只读访问。

现有的规则“admin_or_owner”允许管理员或项目中的任何角色访问项目资源。

policy.RuleDefault(
    "admin_or_owner",
    "is_admin:True or project_id:%(project_id)s",
    "Default rule for most non-Admin APIs."
)

新的规则“project_reader_or_admin”将允许管理员、project-member 和 project-reader 访问项目资源。

在 tacker 策略文件中添加 project_reader 策略。

RULE_PROJECT_READER = 'rule:project_reader'
RULE_PROJECT_READER_OR_ADMIN = 'rule:project_reader_or_admin'

policy.RuleDefault(
    "project_reader",
    "role:reader and project_id:%(project_id)s",
    "Default rule for Project level read only APIs."
    deprecated_rule=DEPRECATED_ADMIN_OR_OWNER_POLICY)

policy.RuleDefault(
    "project_reader_or_admin",
    "rule:project_reader or rule:context_is_admin",
    "Default rule for Project reader or admin APIs.",
    deprecated_rule=DEPRECATED_ADMIN_OR_OWNER_POLICY)

在策略检查字符串中 project-reader 角色

例如，查询以显示单个 VNF 实例的策略检查字符串。现有的规则“RULE_ADMIN_OR_OWNER”允许管理员或项目中的任何角色获取 VNF 实例。

policy.DocumentedRuleDefault(
    name=VNFLCM % 'show',
    check_str=base.RULE_ADMIN_OR_OWNER,
    description="Query an Individual VNF instance.",
    operations=[
        {
            'method': 'GET',
            'path': '/vnflcm/v1/vnf_instances/{vnfInstanceId}'
        }
    ]
)

新的规则“RULE_PROJECT_READER_OR_ADMIN”允许管理员、project-member 和 project-reader 获取 VNF 实例。

policy.DocumentedRuleDefault(
    name=VNFLCM % 'show',
    check_str=base.RULE_PROJECT_READER_OR_ADMIN
    description="Query an Individual VNF instance.",
    operations=[
        {
            'method': 'GET',
            'path': '/vnflcm/v1/vnf_instances/{vnfInstanceId}'
        }
    ]
)

修复现有的 ‘owner’ 规则

现有的“owner”规则允许任何角色用户访问项目资源。引入专用的项目成员和读者角色有助于解决该问题。此外，为了使 project-reader 角色在 Tacker 中表现为 reader 角色，我们需要修复现有的“owner”规则。

project-member 由在项目上具有 member 角色的用户表示。它旨在由在项目中消耗资源的最终用户使用。它继承了 project-reader 的所有权限。

现有的“admin_or_owner”规则赋予项目中的任何角色（例如 foo）访问权限，使其表现为项目的所有者。

policy.RuleDefault(
    "admin_or_owner",
    "is_admin:True or project_id:%(project_id)s",
    "Default rule for most non-Admin APIs."
)

新的规则“project_member_or_admin”将赋予管理员或该项目中的 member 角色访问权限，使其表现为项目的所有者。

在 tacker 策略文件中添加 project_member 策略。

RULE_PROJECT_MEMBER = 'rule:project_member'
RULE_PROJECT_MEMBER_OR_ADMIN = 'rule:project_member_or_admin'

policy.RuleDefault(
    "project_member",
    "role:member and project_id:%(project_id)s",
    "Default rule for Project level non admin APIs."
    deprecated_rule=DEPRECATED_ADMIN_OR_OWNER_POLICY)

policy.RuleDefault(
    "project_member_or_admin",
    "rule:project_member_api or rule:context_is_admin",
    "Default rule for Project Member or admin APIs.",
    deprecated_rule=DEPRECATED_ADMIN_OR_OWNER_POLICY)

在策略检查字符串中 project-member 角色

例如，查询以创建 VNF 实例的策略检查字符串。现有的规则“RULE_ADMIN_OR_OWNER”允许管理员或项目中的任何角色创建 VNF 实例。

policy.DocumentedRuleDefault(
    name=VNFLCM % 'create',
    check_str=base.RULE_ADMIN_OR_OWNER,
    description="Creates vnf instance.",
    operations=[
        {
            'method': 'POST',
            'path': '/vnflcm/v1/vnf_instances'
        }
    ]
)

新的规则“RULE_PROJECT_MEMBER_OR_ADMIN”将允许管理员或 member 角色创建 VNF 实例。

policy.DocumentedRuleDefault(
    name=VNFLCM % 'create',
    check_str=base.RULE_PROJECT_MEMBER_OR_ADMIN,
    description="Creates vnf instance.",
    operations=[
        {
            'method': 'POST',
            'path': '/vnflcm/v1/vnf_instances'
        }
    ]
)

注意

Tacker API 中策略定义为“RULE ANY”的 API 将不会更改。

如何设计功能测试

在当前的基于 sol 的 v1 功能测试用例中，单租户用例使用管理员角色用户进行验证。多租户用例由 member 角色用户进行验证。为了验证 Tacker 中的 project-reader 角色，我们需要创建一个具有 project-reader 角色的新测试用户。然后，新的测试用户将验证基于 sol 的 v1 只读 Tacker API。

备选方案

无

数据模型影响

无

REST API 影响

受影响的 Tacker API 列表

1. VNF 包

   • 创建 VNF 包

   • 列出 VNF 包

   • 显示 VNF 包

   • 删除 VNF 包

   • 从内容上传 VNF 包

   • 从 uri 上传 VNF 包

   • 更新 VNF 包信息

   • 读取单个 VNF 包的 VNFD

   • 使用 HTTP_RANGE 获取上载的 VNF 包

   • 使用 HTTP_RANGE 获取上载的 VNF 包 Artifacts

2. VNF 生命周期管理

   • 创建一个新的 VNF 实例资源

   • 实例化 VNF 实例

   • 终止 VNF 实例

   • 修复 VNF 实例

   • 删除 VNF 实例

   • 显示 VNF 实例

   • 列出 VNF 实例

   • 扩展 VNF 实例

   • 修改 VNF 实例

   • 更改外部 VNF 连接性

   • 显示 VNF LCM 操作发生情况

   • 列出 VNF LCM 操作发生情况

   • 回滚 VNF 生命周期操作

   • 使 VNF 生命周期操作失败

   • 创建一个新的订阅

   • 删除订阅

   • 显示订阅

   • 列出订阅

   • 重试

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

无

其他部署者影响

无

开发人员影响

无

实现

负责人

主要负责人

Manpreet Kaur <kaurmanpreet2620@gmail.com>

工作项

• 在 Tacker 策略中添加 project-reader 和 project-member 规则。

• 添加单元测试用例以验证策略更改。

• 实现功能测试用例以使用 project-reader 角色验证基于 sol 的 v1 只读 API。

依赖项

无

测试

添加单元和功能测试用例以验证新规则。

文档影响

更新 Tacker 策略文档 [2]，添加有关新项目角色的详细信息。

参考资料

[1]

https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html

[2]

https://docs.openstack.org/tacker/latest/configuration/policy.html