UOS 4.0 - Role-Based Access Control（RBAC）

Posted 2021-05-01 同方有云

Role-Based Access Control

1

简介

RBAC，即 Role Base Access Control。而 RBAC-network 主要针对 Neutron 中的网络资源增加了访问控制。RBAC-network 这一功能是在 Neutron 的 Liberty 版本中被引入的。

这里所说的访问是指，用户可以在通过 API/CLI 来查询网络，在网络上创建 Port 这一资源。

在 Neutron 引入 RBAC-network 之前，在 Neutron 中创建的网络（包括其子网）对于访问控制，只具有 shared 属性，并且我们只可以将 shared 属性设置为 True 或者 False。True，即为面向所有租户，来自任意租户的用户都可以访问 shared 属性为 True 的网络，而 False，即为只面向所属租户，只有来自网络所属于的租户的用户可以访问网络。

显然这样对于网络所属租户是不安全的，网络所属的租户应该有权利来决定来自其他哪些租户的用户可以访问本租户的网络，而哪些不能。即租户下面的网络所具有的 shared 属性，应该是可以由租户自己决定如何对第三方租户开启访问共享的。而不是原来的全开或者全关的简单二元属性。

在 RBAC-network 引入后，对于 shared 属性，其拥有了一个中间状态。租户可以在网络的 shared 为 False 的情况下，通过添加针对网络的访问权限，来支持指定的第三方租户访问自己所拥有的网络。需要说明的有以下几点：

1. 作为终极用户，admin 并不受 RBAC-network 的影响，即使没有被租户添加访问权限，admin 用户仍然可以访问租户的网络；

2. 在引入 RBAC-network 后，网络的 shared 属性的原有特性仍然被保留了，即当 shared 被设置为 True 时，网络仍是面向所有租户的，因此为了使 RBAC-network 生效，以及达到访问控制的目的，租户网络的 shared 属性不建议更新为 True；

3. 网络所属租户对于网络持有最终话语权，网络所属的租户对于网络上的由第三方租户创建的 Port 拥有删除的权利。

在经过访问权限的支持，使得网络联通性被构建后，在网络数据层面的控制则由安全组来管理。

在 Neutron 中被引入 RBAC 支持的，除了网络这一资源外，还有 QoS。而 RBAC 支持开启的权限，目前主要有两种，一种为 access_as_shared，另一种为 access_as_external。

2

实现

除了 Policy 文件的修改，实现 RBAC-network 的主要工作都集中在数据库的接口层面，即增删改查的管理。

引入 RBAC 之后，Neutron 中新添加了 RBACColumns 和 NetworkRBAC 两个类，这两个类共同构成了数据库中的新的表 networkrbacs：

在这张表中存放着针对某一网络所生成 RBAC-network rule 的四元组（object_id， project_id， target_tenant，action）。id 为 RBAC-network rule 本身的 ID。在四元组中，object_id 对应网络所属项目的 ID， target_tenant 对应第三方项目的 ID， action 则对应  'access_as_shared' 和 ‘access_as_external’ 两个 action 之一。

当网络的 shared 属性被设置为 True 时，target_tenant 列的值将为'*'，即通配符。而对于 target_tenant，目前，Neutron 并不会对 target_tenant 的值进行有效性的检查。

对于原有的 ORM 类 Network（对应 Networks 表）和 Subnet（对应 Subnets 表），针对 RBAC 增加了 orm.relationship:

1. db model 中 Network类

   

2. db model 中 Subnet 类

   
   

   这两个属性在 Network 与 Subnet 查询的时候起作用。

   
   

接下来我们要考虑的是 Port，Subnet，Network 这三种 Neutron 核心资源在数据库层面的工作。实际上，对于这三种资源，只有 Network 的创建不会涉及到查询外，Network 的删除，更新，以及 Subnet 和 Port 的增删改查都会涉及到数据的查询。因此本文将主要讲述 RBAC-network 作用于这三种资源的查询工作。

Neutron 对于 RBAC-network 提供支持的代码主要在 CommonDBMixin 类中，主要为两个方法，_model_query 和_apply_filters_to_query。

在_model_query 方法中，通过判断被查询的 Model 是否含有'rbac_entries'属性来判断是否需要对查询语句表达式进行扩展。主要代码片段为：

当查询来自第三方租户时，context.tenant_id 即为第三方的租户 ID，此时 query_filter 表达式扩展的结果为：在 Networks/Subnets 表中查询能够关联到 NetworkRBACs 表中 action 为"access_as_shared"，同时 target_tenant 为自己 ID 或者通配符的记录。

在_apply_filters_to_query 方法中，主体思路一致，这里略过不论。

不同于 Network 和 Subnet，Port ORM 类不具有 rbac_entries 属性。同时对于租户网络上不属于租户的 Port，又需要为租户提供支持查询和删除的能力。为此 RBAC-network 利用到了 query hook 机制来实现对于 Port 的租户权限检查。

query hook 机制的基本思想是由 CommonDBMixin 来实现基本的 query_filter 表达式，而对于不同的 ORM 类，以及不同的 query 场景，则由各个 ORM 类在自己的 hook 方法中生成特定的 query 扩展表达式，并将 hook 方法注册到 CommonDBMixin 类的_model_query_hooks 字典中。当某个 ORM 类通过 CommonDBMixin 的方法被查询时，后者在生成基本的 query 表达式后会检查_model_query_hooks 字典中注册的 query hook，并根据情况扩展 query_filter 表达式。

query hook 机制对于 Neutron 的意义在于，从各个 ORM 类的查询工作中分离了 common query，简化了代码。而对于实现 RBAC-network，query hook 则屏蔽了 Port 与 Network 之间 tenant_id 匹配的细节。

3

RBAC-network 与 Neutron Policy 的冲突与缺陷

首先，通过 CLI/API 对 neutron 的资源进行增删改查时，首先需要经过 Policy 的检查。

在实现 RBAC-network 之前，Neutron Policy 的主要思路是除了 admin 之外，网络的使用者即是网络的所有者。因此 Policy 文件中有着较多的 "admin_or_network_owner" 作为资源操作所需要匹配的 rule。而实现 RBAC-network 之后，Neutron 并没有对 Policy 进行比较好的更新，因此在使用 RBAC-network 时，将会遇到一些与现有 Neutron Policy 存在冲突的地方。

主要的冲突与缺陷集中在 Port 上，与 Port 的创建于更新操作有关。虽然创建 RBAC-network rule 后，租户授予第三方租户在自己网络上创建 Port 的权限，但这种权限是有限的，第三方无法通过指定 mac_address，fixed_ips，port_security_enabled 等参数的方式来创建 Port。而对于更新 Port，操作本身的检查 rule 为仅支持 admin 或者 Port 的所有者，但当更新操作带有参数时，一些参数的检查 rule 则仅仅支持 admin 或者 Network 所有者，这些参数包括 mac_address，fixed_ips，port_security_enabled 等。这将导致对于租户网络上的第三方 Port，只有 admin 才可以更改其部分属性的情况。

而对于 Subnet，则可能存在另外一些令人困惑的问题。在 RBAC-network 的支持下，第三方可以查看到租户的网络以及网络信息，并且也可以在网络中传建 Port，但却无法在网络中创建子网。

对于 Port 这一资源，建议根据需求适当的改变 Policy 文件，可以避免上述冲突与缺陷。

4

验证

5

总结

从验证来看，RBAC-network 中，第三方租户，只能使用该网络（包括端口的创建，删除等），但是子网的操作只能由 admin 或者网络 owner 才能进行。在某些特定需求下，我们可以修改 Neutron Policy 文件来进行权限更细致的管理，结合 rbac 一般可以实现更丰富的功能。