背景和範圍
當前大數據團隊沒有一個統一的操作權限控制和管理平臺，對於分析師在服務器上的權限，目前都是給予對應分析節點的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控制
權限表裏的權限對於資源的定義如下：
數據存儲
