本小节将会为您介绍基于交互式分析(Hologres)的简单权限模型。

背景

交互式分析兼容Postgres,使用与Postgres完全一致的权限系统(简称专家模式,详情可以参见专家模式授权)。典型的Postgres权限系统划分非常严格,在实际业务场景中使用时,业务人员想要给某个用户授权,需要执行大量的授权语句。不同的角色有不同的权限,在操作上非常繁琐,有时也会出现某条授权语句遗漏导致某个权限缺失的情况。并且每新增一个用户就需要执行相同的批量授权语句,浪费大量时间。除此之外,尽管我们提供了Postgres的标准授权语句作为参考,但不同的业务方有不同的使用习惯,面对不同的权限,常常难以准确执行正确的授权语句,在权限管理方面容易混乱,这在一定程度上也会给业务带来一定的安全风险,同时也加大了用户的管理成本,时间成本和使用成本,事倍功半

为解决以上业务痛点,交互式分析(Hologres)在PostgreSQL权限的基础上,提供一种粗粒度的简单权限模型(Simple Permission Model,SPM)。简单权限模型以DB作为维度,划分admin(管理员),developer(开发者),writer(读写者)以及viewer(分析师)四种角色,用户通过少量的权限管理函数,即可对DB中的对象进行方便且安全的权限管理。

简单权限模型介绍

在简单权限模型中,对每个DB而言,有6种权限等级:

  • 超级管理员:superuser
  • DB管理员:<db>_admin
  • 开发者:<db>_developer
  • 读写者:<db>_writer
  • 分析师:<db>_viewer
  • 其他用户:不属于以上任何用户组的用户

具体每个角色对应的权限见下表:

角色 权限
Superuser 整个实例的管理员,拥有实例的所有权限。
<db>_admin
  • 某个DB的管理员(admin);
  • admin组是developer组的成员,权限是developer组、writer组、viewer组权限的超集;
  • 是某个DB的owner,可以删除DB;
  • 可管理当前DB下<db>_admin、<db>_developer、<db>_writer和<db>_viewer四个用户组的成员,包括新增、移除用户组成员;
  • 可以创建用户,并将用户加入某个用户组;
  • 可以在该DB创建对象,例如schema,并能对对象进行增删改查;
  • 可以在DB级别修改DB的配置项。
<db>_developer
  • DB下的开发者(developer);
  • developer组是writer组的成员,权限是writer组、viewer组权限的超集;
  • 该DB所有schema下除系统对象以外的所有表、外表、类表对象(如视图等)、Function、Procedure、Foreign Server、FDW、Type及Language的owner,可以增删查改所有schema下的所有表;
  • 所有schema的USAGE、CREATE权限,可以在任意非系统schema下进行创建表,创建视图,创建外表等DDL操作。
<db>_writer
  • DB下的读写者(writer);
  • writer组是viewer组的成员,权限是viewer组权限的超集;
  • schema下所有表、外表及类表对象(如视图等)的数据,即拥有SELECT、INSERT、UPDATE、DELETE等权限;
  • 可以增删查改所有schema;
  • 可以访问或使用developer所拥有的Function、Procedure、Foreign Server、FDW、Type及Language等对象;
  • 所有schema的USAGE权限,不可进行DDL操作。
<db>_viewer
  • DB的分析师(viewer);
  • 可以读取所有schema下所有表、外表及类表对象(如视图等)的数据,即拥有SELECT权限;
  • 可以访问或使用developer所拥有的Function、Procedure、Foreign Server、FDW、Type及Language等对象;
  • 所有schema的USAGE权限;
其他用户
  • 没有加入以上任何用户组的用户,即为其他用户;
  • 对DB没有CONNECT权限,无法连接到该DB;
  • 如需访问某个DB,需要<db>_admin或Superuser授权加入上述用户组。
  • 开启简单权限模型后,需要尽快将需要访问DB的用户加入到上述用户组,以防止用户无权访问DB而对业务运行造成影响。

关于如何使用简单权限模型为新用户授权,可以参见下一章节简单权限模型的使用。