背景和范围
当前大数据团队没有一个统一的操作权限控制和管理平台，对于分析师在服务器上的权限，目前都是给予对应分析节点的EC2机器账号，且为了方便操作和管理都是给予的管理员权限，因此安全性风险较大；对于数据开发者，主要通过分配IAM控制AWS的操作权限；对于team的所有人都是通过分配aws的ak,sk在本地进行操作赋权；随着数据平台的不断的丰富和完善，需要在各组件之上做认证，鉴权和审计等管理，数据权限管理平台主要是为了统一所有人的操作权限而设计。开源权限组件apache ranger和apache sentry存在以下问题:
- 如在命令行中或脚本中，使用export HADOOP_USER_NAME=hadoop方式或使用对应java api方式传入hadoop用户，执行hadoop相应命令，则会绕过所有权限检查
- 不支持spark sql访问hive表权限校验，只能控制到目录文件级别
- 无法精细粒度控制表权限，如对特殊表的下载权限
综上，数据平台团队准备自研数据权限管理系统。
目标
- 采用公共模块或者公共配置文件去做用户权限管理，对服务器的账号权限及开源组件的自带账号权限服务解耦
- 每个组使用不同的账号进行查询集群的数据（表和文件），所有人都通过公司内部统一账号平台office365使用
- 所有查询集群数据的用户账号都需要经过权限管理模块验证，无权限的操作应该给予提示信息。
- 根据各组的职责限定该部门的人员使用的账号只能查询归属于该组的数据。
非目标（可选）
- 操作日志审计功能(有额外独立的日志系统会对大数据平台所有操作做审计)
- 鉴权sdk（独立的服务）
- 认证（采用公司内部的office365作为统一登录入口）
- 对系统的菜单操作的功能权限不涉及，只专注数据权限
- 数据侧的api未来可能作为一个候选权限管理加入
概要设计
整体结构
![]()
模块交互
管理后台从云端获取使用管理后台的user接口得到所有使用系统的用户列表
在管理后台里对用户列表中指定的用户进行授权，在授权的过程中，把用户的email,name信息同步到数据侧RDS，并保存权限关系到数据侧的RDS中，保存成功后，直接刷新数据侧的鉴权API使用的内存缓存
其他平台：如数据集成，数据调度，执行引擎，数据查询，元数据等系统涉及到的资源都只会依赖数据权限管理系统里的权限，不受其他约束
执行引擎先查询该用户提交的任务里的资源是否拥有权限，如果有，则检查权限是否符合期望，如果符合，则执行其他操作，会进一步将权限更新到权限配置里，如用户拥有db的create权限，则该用户在此db下新建的表，默认对该用户有all的权限，对该用户所在的组内其他人仅有read权限
用户能够在以上平台内操作，当前仅当用户拥有了至少一项权限，否则对不同操作类型，仅有默认以下权限：
db:展示当前所有database名称的权限
table:展示当前所有database的不同database下的所有table名称权限
path:展示当前所有的bucket名称权限
详细设计
实体模型
考虑到鉴权是一个高频操作，而赋权是一个低频操作，因此尽可能的减少表关联，所以使用了简化的RBAC模式
user表里的admin是数据平台系统级别，拥有admin权限的用户将不需要任何验证，对资源具有所有管理权，所有权限邮件审批都会给admin发邮件
user_group_user的group_admin是group级别（group可以没有group_admin），只对该group管理的资源有权限管理，该组的权限邮件的审批会给group_admin和admin同时发邮件，且group_admin具备审批资格
ttl主要是为了对权限做过期时间用的，常用场景是下载表数据场景，可通过ttl控制
权限表里的权限对于资源的定义如下：
数据存储
