伴鱼大数据权限系统的设计与实现

背景

数据访问方式

• Hive：有两种方式，一是 Hive CLI，一个逐渐被淘汰的工具，但目前仍然在各种脚本中被使用。Hive CLI 是一个胖客户端，官方推荐使用 Beeline CLI（HiveServer2 JDBC Client）替代它，并建议在生产环境中使用其远程模式（轻客户端模式）。另一个是 HiveServer2 JDBC API。
• Presto：Presto JDBC API。
• Hadoop：HDFS CLI。
• Flink：HDFS Client API。

数据访问渠道

• 集群节点上安装的各类客户端工具。
• Metabase（BI 平台）：Metabase 可以配置各种「数据源」，数据报表开发时必须选择一个对应的「数据源」。目前我们主要使用两类数据源：Hive 数据源（使用 HiveServer2 JDBC API 的方式）以及 Presto 数据源（使用 Presto JDBC API 的方式）。而对于开发之后的报表，Metabase 内部实现了一套自己的授权方式。
• 离线开发平台（DolphinScheduler，简称 DS）：DS 同样抽象了数据源的概念，目前主要使用的 Hive 数据源（使用 HiveServer2 JDBC API 的方式）。此外，DS 也支持 Shell 脚本类型的工作流节点，使用此类方式脚本中基本是采用 CLI 的访问方式，本质上要求 DS worker 节点提前安装好各类客户端工具。
• 实时开发平台：与具体的实时任务相关，主要体现在与 Hive 集成的任务。

设计目标

• 尽量收紧非数仓团队的各类权限：此为核心目标。非数仓团队访问数据主要通过是通过 Metabase，目前针对不同的数据库（如：Hive）都基本是使用同一个数据源，该数据源配置的拥有最高权限，导致各方都可以查看任何数据。
• 逐渐规范化数仓团队数据访问方式：逐步替换 Hive CLI 方式至 Beeline CLI。
• 统一整合权限系统与各相关系统的权限操作：在大数据权限系统平台即可完成各类授权的操作。

调研

用户认证

1. Hive

2. Presto

3. Hadoop

权限认证

1. Hive

2. Presto、Hadoop

系统设计

用户认证

<property>  <name>hive.server2.authentication</name>  <value>LDAP</value></property> <property>  <name>hive.server2.authentication.ldap.baseDN</name>  <value>ou=People,dc=ipalfish,dc=com</value></property> <property>  <name>hive.server2.authentication.ldap.url</name>  <value>ldap://*****:389</value></property> <property>  <name>hive.server2.authentication.ldap.userDNPattern</name>  <value>cn=%s,ou=bigdata_user,ou=People,dc=ipalfish,dc=com</value></property>

权限认证

用户和用户组

private RangerPrestoAccessRequest createAccessRequest(RangerPrestoResource resource, SystemSecurityContext context, PrestoAccessType accessType) {String userName = null;Set<String> userGroups = null;
   if (useUgi) {     UserGroupInformation ugi = UserGroupInformation.createRemoteUser(context.getIdentity().getUser());
     userName = ugi.getShortUserName();     String[] groups = ugi != null ? ugi.getGroupNames() : null;
     if (groups != null && groups.length > 0) {       userGroups = new HashSet<>(Arrays.asList(groups));     }   } else {     userName = context.getIdentity().getUser();     userGroups = context.getIdentity().getGroups();   }
   RangerPrestoAccessRequest request = new RangerPrestoAccessRequest(     resource,     userName,     userGroups,     accessType   );
   return request; }

权限等级

权限策略

• Access：正向策略。如一个数据表有三个字段，我们可以为每一字段创建一条 Access 策略，将申请了权限的用户或组配置进策略即可。乍一看，这种策略即可满足我们的需求，不过考虑这么一个场景：一个拥有 50 个字段的数据表，某一个用户申请其中 40 个字段的权限（另外一些字段的权限等级可能属于 P0 级别）。当想要查看表数据时，一般的写法是「SELECT * FROM Table」，这种形式的语句在权限认证环节要求具备全部字段的权限，否则将会返回权限不足的错误，而我们期望是对于未授权的字段可以使用特殊的脱敏标识符打标，这就需要借助到 Ranger 提供的另一种 Mask 策略。
• Mask：补充策略。该策略用于保护敏感数据，对数据进行脱敏。Mask 策略是建立在 Access 策略之上的，即使用 Mask 策略优先得具备列的 Access 策略。因此当用户申请权限时，我们可以为用户授予数据表全部字段的 Access 策略（只需一个策略，策略中的 column 配置成通配符 * ）的权限，同时为每一个字段生成 Mask 策略，对于没有申请权限的字段，将 User 或 Group 配置进策略即可。

注：所有在 Ranger Admin 配置的策略将由 Ranger Plugin 中的线程定期 Pull 至组件，并在运行时执行权限认证。

• 权限申请工单
  

• Access Policy
  

• Mask Policy
  

策略配置

1. 同步创建

• 数据建模平台：数据建模平台约束了建表规范，同时收集了表的附加元信息，如表字段的权限等级，这些元信息将通过 API 传递至 Hive。可见，数据建模平台本质上是对建表操作的封装和约束，可以实现同步初始化策略的目的。
• CLI：指代 Beeline。由于并未完全约束用户在建模平台建表，开发人员可以直接在自己脚本中通过 CLI 直接建表，这种情况下表的元信息是缺失的。

2. 异步创建

值得一提的是，字段权限等级的修改有且仅能在元数据中心进行，等级的修改将影响到对应的权限策略。对于这一事件，将通过同样的方式，被权限系统后台监听，并触发相应的动作。

• Workflow State Machine：工作流状态机，负责各级工单状态流转。
• EventListener：负责监听元信息变更事件。
• Deployment：负责将策略部署至 Ranger。同时，由于涉及到权限整合还有和 Metabase 的交互，将在下文阐述。

权限整合

1. 报表开发权限
   任意平台用户都具备报表的开发权限，但开发一个报表需要选择一个对应的「数据源」，因此开发权限体现在对于「数据源」的权限控制上。我们在权限系统提供了「同步账户」的操作，用户可以执行此操作，操作中的一个步骤就是创建数据源，使用的是其对应的用户名和密码，用户开发报表时选择自己的数据源即可，会为该对象的 Metabase 账户授予此数据源的权限。
2. 报表查看权限
   Metabase 报表权限是按照「分组」进行授权的，平台用户需加入某一个「分组」，然后为此「分组」授予报表权限，用户方可查看报表。因此「同步账户」时还会为用户或用户组创建与之对应的「分组」，同时将其下所有成员的 Metabase 账户加入此「分组」。报表的权限申请提供了单独的申请入口，用户填入报表地址即可，工单进入不同的审批流程，审批完成则将自动为其对应的「分组」授予权限。

总结

如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享

·END·

相关阅读：

• Redis基础、高级特性与性能调优
• HAProxy从零开始到掌握
• Redis官方的高可用性解决方案
• 内存耗尽后Redis会发生什么
• 【Redis】缓存的三大问题及其解决方案
• 一步步实现 Redis 搜索引擎