Role-based Access Control for Networks¶

Launchpad 蓝图 URL

https://blueprints.launchpad.net/neutron/+spec/rbac-networks

我们需要能够将 Neutron 网络共享给租户的子集，而不是现在这种全有或全无的选择。这将使更多在企业/私有云部署中遇到的网络管理工作流程成为可能。

这将通过一个新的“基于角色的访问控制”表来实现，该表包含对象 UUID、对象类型、目标租户、操作以及代表策略所有者的租户 ID。采用这种通用格式，应该相对容易地将基于角色的访问控制扩展到其他 Neutron 对象和操作。

问题描述¶

当前共享 Neutron 网络的选项是二元的。网络要么共享给每个租户，要么根本不共享。这消除了许多在“传统”网络配置中出现的组概念，在这些组概念中，一类设备或用户可以访问网络，而其他用户则不能。虽然这对于许多只将网络抽象用作 L2 隔离工具的公共云部署来说是可以的，但它未能满足许多私有云用例。

例如，管理员无法定义一个可以访问受限资源（例如，数据组播/广播源）的网络，并且仅允许某些租户将其服务器连接到该网络。同样适用于可能具有特殊审计要求、安全控制、服务保证、浮动 IP 池等的网络。

在类似的情况下，云管理员可能希望完全消除大多数租户创建网络、子网和路由器的能力，而只是让他们连接到预先创建的网络，这些网络对应于组织中的部门。

提议的变更¶

引入一个新的 RBAC 表，用于控制租户之间 Neutron 网络的共享。此外，还引入一个新的 API 来处理 RBAC 条目，该 API 将足够通用，可以轻松扩展到人们希望由 RBAC 控制的其他资源。

然后将围绕共享网络的逻辑重写，以利用新的 RBAC 代码作为第一个实现。网络上的当前“shared”属性将被映射到新表中的通配符条目，以保留向后兼容性（更多详细信息如下）。

对象的转发语义和所有权将不受此规范的影响。此规范仅影响允许哪些用户连接到网络 - 而不是他们如何连接或之后会发生什么。

为了保持简单，这将从一开始就采用仅允许列表模型。也就是说，操作列不能是表示某个租户不能执行某事的否定。

即使端口不属于他们，租户也可以删除他们拥有的网络上的端口。这是为了允许租户对他们拥有的网络拥有最终决定权。

数据模型影响¶

每个 RBAC 条目将包含以下重要信息：对象标识符、对象类型、租户标识符和允许的操作。所有条目都允许其描述的操作。目前不会有“拒绝”规则。

对象 ID 只是应用于 RBAC 条目的对象的 UUID。

对象类型只是描述对象 ID 引用的对象的类型。对于此规范，它将始终是“network”，因为这是当前引入 RBAC 的唯一对象。此信息是冗余的，因为对象 ID 是唯一的；但是，这将允许我们为我们想要支持的每种类型创建关系表。这些允许在对象删除时将 RBAC 条目的清理留给数据库 CASCADE 功能。对象类型不存储在数据库中，它用于确定使用哪个表。

目标租户将是授予在目标对象上执行操作权限的租户（也称为项目）ID。此条目也可能是星号，以表示它适用于所有租户。

操作将描述租户可以对对象执行的操作。为了本规范的目的，我们将从一开始只拥有一个操作，这将类似于“access_as_shared”，以指示租户可以像访问共享网络一样访问它。然后，将来可以轻松地将其扩展到包含类似于“access_as_external”的内容，以便为外部网络提供 RBAC。操作将通过 API 为每种类型发现。

最后，每个 RBAC 条目还将具有一个租户 ID，指示创建策略本身的租户。这通常与共享对象的相同租户相同，但如果是在其他租户的网络上由管理员创建的策略，则可能并非如此。

DB Tables¶

应用于 RBAC 的每种对象类型都将获得自己的 RBAC 表。唯一约束仅在所有 API 字段上。（即，每个租户可以为每个对象拥有多个具有不同操作的条目）。因此，对于此规范，将只有一个新的 networkrbacs 表。

“shared”列将从 networks 表中删除，并将其替换为查询新的表，以查看该网络是否存在“*”以及“access_as_shared”操作。

REST API 影响¶

这些 RBAC 条目将在一个新的 API 端点（“/rbac-policies”）上启用。为了创建对象的条目，租户必须是该对象的所有者。

为了创建具有通配符成员资格的条目，默认情况下请求必须在管理员上下文中执行，但可以通过 policy.json 启用所有租户。这是为了防止租户通过创建通配符条目来污染其他租户的网络列表。

将来，如果遇到对象所有者希望赋予另一个租户将对象共享给更多租户的能力的用例，我们可以重新审视以添加“reshare”操作或类似操作。

属性名称	类型	访问	默认值	验证/转换	描述
id	字符串 (UUID)	R	自动		RBAC 条目的 ID
tenant_id	字符串 (UUID)	R	自动		RBAC 条目的所有者
object_id	字符串 (UUID)	RW	N/A	对象存在	受 RBAC 影响的对象
object_type	string	RW	N/A	具有 rbac 表的类型	对象类型
target_tenant	string	RWU		string	条目影响的租户 ID。 * 表示所有
操作	string	RW	N/A	对象的操作	对象上允许的租户操作

Example Entries¶

一个传统的共享网络：* object_id = <some_net_id> * object_type = network * target_tenant = * * action = ‘access_as_shared’ * id = <uuid> # 自动生成 * tenant_id = <uuid-of-policy-creator> # 由 API 生成

共享给特定租户的网络：* object_id = <some_net_id> * object_type = network * target_tenant = <some_tenant_id> * action = ‘access_as_shared’ * id = <uuid> # 自动生成 * tenant_id = <uuid-of-policy-creator> # 由 API 生成

安全影响¶

租户可以相互共享网络。这不应该成为一个主要问题，因为所有权永远不会改变，因此他们仍然需要承担带宽核算和事件响应方面的责任。

如果用户知道他们想要攻击的租户的租户 ID，他们可以将网络共享给该租户，以用可能不堪重负或可能具有欺骗目标租户将其 VM 连接到其中的名称的条目来污染其网络列表。

这可能可以通过默认的网络过滤选项来解决。除非用户请求，否则客户端可以过滤掉共享网络。然后，像 Horizon 这样的 UI 可以用一个标志显示共享网络，以将其与租户的网络区分开来。有什么想法吗？

通知影响¶

N/A

其他最终用户影响¶

用于设置这些权限的新 CLI 工作流程

neutron rbac-create <net-uuid|net-name> –type network –target-tenant <tenant-uuid> –action access_as_shared

更新：* neutron rbac-update <rbac-uuid> –target-tenant <other-tenant-uuid>

列出条目

neutron rbac-list

显示条目

neutron rbac-show <object-id>

删除

neutron rbac-delete <rbac-uuid>

列出可用操作

neutron rbac-list-actions <object-type>

不应影响常规的全局共享网络工作流程。仅需要新的 API 用法才能进行细粒度的条目。

从共享网络给它的租户的角度来看，网络将显示为“shared”，就像全局共享网络一样。

性能影响¶

现在，检查网络的共享属性将涉及连接到另一个表。网络列表的影响将在代码审查期间量化。

其他部署者影响¶

N/A

开发人员影响¶

N/A

社区影响¶

此更改不应以任何重大方式影响社区。它将引入一种受限共享的新方法，但对于树外驱动程序/插件来说，没有什么是重大的。

备选方案¶

N/A

IPv6 影响¶

N/A

实现¶

负责人¶

kevinbenton sballe

工作项¶

添加 DB 模型、REST API 更改、UT 到 Neutron 服务器
调整现有的“shared”属性以使用 rbac 并添加迁移脚本
更新客户端以 CRUD RBAC
添加 API 测试

依赖项¶

N/A

测试¶

Tempest 测试¶

N/A。 API 测试应该足够

功能测试¶

可能不需要此工作的任何功能测试。所有这些都在 API 层，不会影响数据平面。

API 测试¶

执行 RBAC 条目的基本 CRUD
确保在更改 RBAC 条目时显示和隐藏网络
删除具有共享网络的另一个租户的端口

文档影响¶

用户文档¶

需要添加添加 RBAC 条目的工作流程。正常共享网络的流程应该相同，因此现有的文档不需要更改。

开发人员文档¶

需要记录新的共享 API。

参考资料¶

这里有一条喷火的龙

__(‘)<~~~ ____)

基于角色的网络访问控制