大數據集群的基本是數據以及用於計算的資源，企業將相應的數據和資源開放給對應的用戶使用，防止被竊取、破壞等，這些都涉及到大數據安全。基於以上關鍵點，考慮到美圖公司原有的系統較為龐大複雜，在第一階段內我們採取輕量級的改造方案進行了大數據集群安全的初探索，接下來通過本文與大家交流相關經驗。
由於美圖的大數據集群安全迫在眉睫，主要需求有以下幾個方面：
- 支持多組件，最好能支持當前公司技術棧的主要組件，HDFS、HBASE、HIVE、YARN、STORM、KAFKA 等；
- 支持細粒度的權限控制，可以達到 HIVE 列，HDFS 目錄，HBASE 列，YARN 隊列，STORM 拓撲，KAKFA 的 TOPIC；
- 開源，社區活躍，按照現有的集群改情況造改動儘可能的小，而且要符合業界的趨勢。
選擇大數據安全組件
有了集群安全的需求的下一步就是選擇合適的大數據安全組件，目前比較常見的安全方案主要有三種：Kerberos(業界比較常用的方案)、Apache Sentry（Cloudera 選用的方案，cdh 版本中集成）和Apache Ranger(Hortonworks 選用的方案，hdp 發行版中集成)。
Kerberos
Kerberos 是一種基於對稱密鑰的身份認證協議，作為一個獨立的第三方的身份認證服務，可以為其它服務提供身份認證功能，且支持 SSO。
*SSO，即 Single Sign On單點登錄。客戶端身份認證後，可以訪問多個服務，如 HBase/HDFS 等。
圖 1：Kerberos 原理圖
如圖 1 所示，Kerberos 的協議主要分為 3 個階段：Client 向 KDC 申請 TGT；Client 通過獲得的 TGT 向 KDC 申請用於訪問 Service 的 Ticket；Client 用返回的 Ticket 訪問 Service。
而這些過程使得它的優點顯而易見：服務認證過程有效地防止 broker datanode regionserver 等組件冒充加入集群；解決了服務端到服務端的認證的同時也解決了客戶端到服務端的認證。
不可避免， Kerberos 也有短板：
- 為了安全性使用臨時 ticket，認證信息會失效，用戶多的情況下重新認證比較繁瑣；
- Kerberos 只能控制你訪問或者拒絕訪問一個服務，不能控制到很細的粒度，比如 hdfs 的某一個路徑，hive 的某一個表，對用戶級別上的認證也沒有實現(需要配合 LDAP 服務集成)。
Apache Sentry
Apache Sentry 是 Cloudera 公司發佈的一款 Hadoop 安全開源組件，它提供了細粒度級、基於角色的授權。
圖 2：Apache Sentry 架構圖，via Apache Sentry 官網
如圖 2 所示，Apache Sentry 目前支持 Hive、Impala、HDFS 等主流組件，它的優點如下：
- 支持細粒度的 HDFS 元數據訪問控制，對 Hive 支持列級別的訪問控制；
- 通過基於角色的授權簡化了管理，將訪問同一數據集的不同權限級別授予多個角色；
- 提供統一平臺，方便管理；
- 支持集成 Kerberos。
但 Apache Sentry 支持的組件種類較少，無法支持 Hbase、Yarn、Kafka、Storm等常見組件。
Apache Ranger
Apache Ranger 是 Hortonworks 公司發佈的 Hadoop 安全組件開源組件，經過調研我們發現它的優點非常多：
- 提供細粒度級的權限控制；
- 權限模型基於訪問策略；
- 權限控制插件式，策略管理統一、方便；
- 支持各式操作的審計日誌，提供統一的查詢接口和界面；
- 支持組件豐富，如 HDFS、HBase、Hive、Yarn、Kafka、Storm 等；
- 支持和 Kerberos 的集成；
- 提供 Rest 接口，可供二次開發。
Apache Ranger 系統架構及實踐
圖 3 ：Apache Ranger 架構圖
如圖 3 Apache Ranger 架構圖所示，Ranger Admin 可以支持多種組件，如 HDFS、HBase、Hive、Yarn、Kafka、Storm 等，這些組件可以進行符合標準的自定義拓展再加入到系統中，每個組件通過不同的安裝節點實現（如 Hdfs 安裝在 NameNode 上）。Ranger Admin 也可以通過獨立設置的 SDK 與開放平臺進行連接，實現對用戶、組以及策略的管理。
權限模型
訪問權限定義了「用戶-資源-權限」這三者間的關係，Apache Ranger 基於策略來抽象它們之間的關係，進而延伸出它的權限模型。
用戶
由 User 或 Group 表示，User 代表訪問資源的用戶，Group 代表用戶所屬的用戶組。
資源
不同的組件對應的業務資源是不一樣的，比如
- HDFS 的 FilePath
- HBase 的 Table、Column-family、Column
- Hive 的 Database、Table、Column
- Yarn 的 Queue
權限
由(AllowACL, DenyACL)來表達，類似白名單和黑名單機制，AllowACL 描述允許訪問的情況，DenyACL 描述拒絕訪問的情況。它的權限控制十分細粒度，不同的組件對應的權限是不一樣的：HDFS 支持 Read、Write、Execute；HBase 支持 Read、Write、Create、Admin；Hive 支持 Select、Create、Update、Drop、Alter、Index 、Lock、Read、Write；Yarn 支持 submit-app、admin-queue。
權限實現
Apache Ranger 的權限二元組是由允許和拒絕組成，相當於白名單與黑名單。我們會在 Ranger Admin 的項目裡配置一些策略，具體到某一個組件會定期通過 REST 接口把所擁有的策略拉取到相應的服務上，根據策略執行訪問決策樹，並且記錄訪問審計。
具體的策略執行過程如圖 4 所示，假設我們發起一個請求，以 Hive JDBC 的操作進行模擬，到了 HiveServer 2 裡的策略，先將拒絕的策略進行匹配（即先訪問黑名單），匹配到黑名單之後再匹配黑名單裡的黑名單，這是一個負負得正的過程，相當於允許訪問。到了允許訪問的階段再去匹配它的白名單，若白名單匹配到拒絕策略也是直接進行「策略下放」的操作。所有都匹配成功之後，就享有「允許訪問」的權限。
*如果沒有policy能決策訪問，一般情況是認為沒有權限拒絕訪問，然而Ranger還可以選擇將決策下放給系統自身的訪問控制層
圖 4
總結以上策略優先級的處理邏輯可得：
- 黑名單優先級高於白名單
- 黑名單排除優先級高於黑名單
- 白名單排除優先級高於白名單
每個權限控制組件會有自身的權限接口，Ranger 將它們實現之後重寫一遍之後，經過權限控制進行權限驗證，接下來逐個組件介紹它們的實現原理。
HDFS
hdfs-site.xml 會修改如下配置：
<property>
<name>dfs.permissions.enabled/<name>
<value>true/<value>
<property>
<name>dfs.permissions/<name>
<value>true/<value>
<property>
<name>dfs.namenode.inode.attributes.provider.class/<name>
<value>org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer/<value>
所有的 permission 開啟之後將 HDFS 的實現類替換成 Ranger 的實現類，這個實現類會在 HDFS 啟動的時候加載一些鉤子函數，加載後所有權限都會通過實現類進行訪問，同時它會拉取一些訪問策略的線程，該線程通過 REST 請求拉取 Ranger Admin 上配置的策略，同時在內存和本地目錄中備份，這個配置更新過程約 30S。
加載過程如圖 5 所示：
圖 5
HBase
hbase-site.xml 會修改如下配置：
<property>
<name>hbase.security.authorization/<name>
<value>true/<value>
<property>
<name>hbase.coprocessor.master.classes/<name>
<value>org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor/<value>
<property>
<name>hbase.coprocessor.region.classes/<name>
<value>org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor/<value>
加載過程如圖 6 所示：
圖 6
Hive
hiveserver2-site.xml 會修改如下配置：
<property>
<name>hive.security.authorization.enabled/<name>
<value>true/<value>
<property>
<name>hive.security.authorization.manager/<name>
<value>org.apache.ranger.authorization.hive.authorizer.RangerHiveAuthorizerFactory/<value>
加載過程如圖 7 所示：
圖 7
Yarn
yarn-site.xml 會修改如下配置：
<property>
<name>yarn.acl.enable/<name>
<value>true/<value>
<property>
<name>yarn.authorization-provider/<name>
<value>org.apache.ranger.authorization.yarn.authorizer.RangerYarnAuthorizer/<value>
加載過程如圖 8 所示：
圖 8
其他組件（如 Kafka、Storm 等）的原理也如同以上幾個例子，通過實現接口類實現。
美圖 Ranger 相關實踐
基於美圖數據技術團隊的現狀，綜合以下幾點考慮進行分析比對，我們選擇了 Apache Ranger ：
- 多組件支持，基本覆蓋美圖現有技術棧的組件；
- 支持審計日誌，方便查找某個用戶在某臺機器上提交的任務明細，問題排查反饋通過溯源可以快速完成；
- 擁有獨立用戶體系，可以去除 Kerberos 用戶體系，方便和其他系統集成，同時提供各類接口調用。
考慮到美圖數據平臺系統較為龐大複雜，不宜進行太大規模的變動遷徙，我們在第一階段根據自身情況打造了輕量級的改造方案對大數據集群安全進行了初探索，主要分為以下幾個部分：
1.由於美圖在調用各服務過程中使用 hdfs shell、hbase-shell、hive-jdbc 只能獲取到用戶信息，在只有組策略時無法生效。因此我們必須要加入 ldap 組件同步用戶組信息，這就增加了系統的複雜性，通過改寫 Ranger-Admin 代碼，在客戶端 plugin 獲取策略時將組權限賦予用戶，實現了組策略功能。
2.同時我們針對 Ranger 的 api 封裝了一個自己的 SDK，方便美圖數據開放平臺集成 Hive、HDFS、HBase 等相關組件的Ranger 服務調用。
3.由於開源社區的 Ranger 工程標準不統一，我們針對性按照美圖大數據研發標準進行自己的版本定製和優化，方便線上運維及日常維護。
以上就是我們第一階段的實踐，在接下來的文章中將會與各位交流美圖數據技術團隊在 Ranger 上進行第二、三階段的實踐技術經驗，歡迎持續關注。
閱讀更多 美圖數據技術團隊 的文章
