ACL方案的调研和设计

[shengofsun]

背景

有了身份认证(参见 #166)之后，我们就可以给系统添加ACL控制了。系统需要ACL方案的主要出发点在于：

• 为了杜绝用户拿到shell客户端对集群私自做不合时宜的操作：如自己去做负载均衡，或者私自建表。
• 为了防止用户在做某些危险操作时候出现失误：比如删表时候敲错了表名
• 对数据的安全性提供更高级别的保护：如防止没有权限的用户去读、写某些数据
• 对某些操作提供审计的功能：如可以查询到表是谁建的，谁删除的。

此外，在设计ACL方案的时候，应该多参考HBase的设计

有哪些操作需要做权限规范

1. 所有meta_server的纯查询rpc
2. 所有meta_server的纯查询的remote_command
3. 所有replica_server的纯查询的remote_command
4. 集群的运维调整：主要就是set_meta_level, propose命令和balance命令
5. 涉及到某个表的操作：
   • 创建表
   • 删除表
   • 召回表
   • 表的冷备份、热备份、split、从冷备中恢复数据、设置表的环境变量
   • 表的读、写(包括又读又写的inc、check_and_mutate等)
6. 其他集群级别的操作：
   • 冷备份相关：创建冷备份，禁用、启用冷备份，修改冷备份的相关参数。
   • 元数据恢复

权限设计

参考HBase的设计，数据库系统的权限设计是可以从两个维度来考虑的：

1. 所授予权限起作用的数据粒度。具体到Pegasus里，权限可以在两个粒度里起作用：
   • 集群粒度
   • 表粒度
2. 权限的分类，HBase一共划分了如下几个类别：
   • Admin(A)：某个粒度内的Admin权限，意味着对这个数据集有着很高的控制权限。
   • Create(C)：Create权限，意味着可以创建一些资源。
   • Write(W)：某个粒度中的写权限
   • Read(R)：某个粒度中的读权限
   • Execute(X)：某个粒度中的执行权限，可以执行一些coprocessor函数。

如果把上面的权限类别对应到Pegasus中，不一定所有的都适用。哪怕仅仅是部分的采用，这也是一个产品设计层面的问题：

• 比如我可能只希望用户进行读写操作就足够了，那么所有的其他的表操作就可以打包为admin权限，统一不开放给用户。而如果换个角度，manual compaction要开放给用户；那么可能就需要加入一个execute的权限位，这个权限意味着用户可以设置表的环境变量来对表进行影响。
• 再比如从集群的角度来看，如果所有的集群操作都要交由系统的维护人员进行，那么可能建表、删表等一系列操作都打包为admin权限即可；否则，可能要把建表等一些操作拆分一个Create权限出来。

下文给出一个建议的权限方案。

表级别的权限建议

对于表级别的一个建议权限方案为：

1. read权限：可以执行表的读操作
2. write权限：可以执行表的写操作
3. execute权限：可以修改表的环境变量，进而引发某个表的某些特定行为。
4. create权限：可以给某个表创建热备，可以把某个表加到某个冷备policy中或者从某个policy中移除，可以对表执行split。
5. admin权限：可以删表、召回表；同时具有R、W、E、C四个权限中的所有操作；同时也可以把表中的R、Ｗ、Ｅ、Ｃ、Ａ权限中的一个或多个授予给某个用户。

注意：

• 如果想执行非幂等的写操作(都是先读后写)，需要同时具有R和W的权限。
• R、W、E、C四个权限是相互独立的。一个具有create权限的人，不需要可以读写表中的数据。之所以这么做，是因为做冷备、热备这些操作的一般是运维人员，他们可能更关心表的稳定性和数据的安全性，对数据的内容不一定在意。所以有必要对权限做互斥性的拆分。
• 热备份是一个比较奇怪的操作：发起热备份的人并不关心数据内容，但热备份在执行的时候，是确确实实需要数据的写权限的。考虑到热备时候，数据是由某个replica-server发起写的，而replica-server一定会分配一个特殊的帐号(因为它不可能有任何其他人的kerberos密钥)，我们只要赋予这个帐号相应的权限即可。

集群级别的权限建议

对于集群级别的建议权限方案为：

1. read权限：对集群中的每一个表，有read权限。
2. write权限：对集群中的每一个表，有write权限。
3. execute权限：对集群中的每个一个表，有execute权限。
4. create权限：对集群中的每个表有create权限；并且可以建表，可以从冷备中恢复表；也可以创建冷备policy，可以disable或者enable某个policy，可以修改policy的所有参数。
5. admin权限：拥有1-4规定的所有权限；可以向replica-server或者meta-server发送任意的rpc；同时也可以把集群或者表级别的任何一种权限分配给任何人。

注意：

• 在启动pegasus-server时，我们需要为每个进程本身分配一个kerberos帐号；我们要为这个帐号分配集群的admin权限。从另一个角度来看，这个帐号就是系统的superuser或者root。
• 集群级别的read和write，对于测试集群非常方便。可以让他们共用一个帐号，而不用给他们太细粒度的处理权限。
• 一个具有集群级别create权限的用户，虽然可以创建表，但不能删表(因为他没有对应表的admin权限)。但直觉告诉我们：
  • 我自己建的表，我好歹能删了它
  • 我自己建的表，我应该能对它有全部控制。
    所以我们这里可以对建表的行为稍作调整：建表的时候可以指定一个表的owner，owner对表有admin权限。如果不指定owner，建表人就是owner。

其他权限

所有纯查询meta server或者replica-server的命令和rpc，可以不做ACL限制，这样会简单很多。

可能的实现方案

需要记录的信息有：

• table的owner
• 每个table需要有五个数组: R, W, E, C, A，来分别记录各个权限级别下的用户列表。
• 集群要有五个数据：R, W, E, C, A，来分别记录各个权限级别下的用户列表。

最简单的做法：

1. table的owner和权限表全放到app_info中，这样同步到zk、冷备都变得非常容易。
2. 1带来的问题是，config_sync会重复的同步很多数据到replica-server上，因为一张table只需要有一份权限table即可。可以稍微修改下config_sync的协议，增加一个字段来记录权限表；而在config_sync时，将configuration_update_request.app_info的相关结构都清空。
3. 集群级别的权限表不做冷备份，一旦机房宕机，冷备恢复就丢失这部分信息，因为我们本来就没有集群粒度的冷备恢复。且这部分的用户量是可控的。

如果担心把权限表全放到一个zk znode下会开销较大，可以考虑稍微优化下：

• 在zk上存放多个znode，直接存到某个app_id/acl的目录下即可。这种情况下，可以维持app_info不变。但修改zk元数据的代码可能就会稍微复杂一些了。
• 权限信息从app_info中抽出来后，元数据恢复的功能可能会受影响。这里得稍微修改下代码，最好让每个replica-server在收到ACL信息的时候记录到本地，这样方便恢复。
• 对于用户名长度，以及某个ACL数组中用户名的个数，可以做适当的限制。

其他建议

开发和使用的时候可能会有很多的问题，请修改、补充、完善或者废弃这个文档。

[kirbyzhou]

做ACL的话，应该考虑acl能接入ranger统一管理。

[acelyc111]

Completed by commits in https://github.com/XiaoMi/rdsn prefixed with 'feat(security): ', such as XiaoMi/rdsn#655