前言
2016年，Hadoop迎來了自己十周歲生日茬高。過去的十年，Hadoop雄霸武林盟主之位假抄，號令天下怎栽，引領(lǐng)大數(shù)據(jù)技術(shù)生態(tài)不斷發(fā)展壯大，一時間百家爭鳴宿饱，百花齊放熏瞄。然而，兄弟多了不好管谬以，為了搶占企業(yè)級市場强饮，各家都迭代出自己的一套訪問控制體系，不管是老牌系統(tǒng)(比如HDFS为黎、HBase)邮丰，還是生態(tài)新貴(比如Kafka、Alluxio)铭乾，ACL(Access Control List)支持都是Roadmap里被關(guān)注最高的issue之一剪廉。
歷史證明跳出混沌狀態(tài)的最好方式就是——出臺標(biāo)準(zhǔn)。于是炕檩，Hadoop兩大廠Cloudera和Hortonworks先后發(fā)起標(biāo)準(zhǔn)化運動斗蒋，分別開源了Sentry和Ranger，在centralized訪問控制領(lǐng)域展開新一輪的角逐笛质。
Ranger在0.4版本的時候被Hortonworks加入到其Hadoop發(fā)行版HDP里泉沾，目前作為Apache incubator項目，最新版本是0.6妇押。它主要提供如下特性:
- 基于策略(Policy-based)的訪問權(quán)限模型
- 通用的策略同步與決策邏輯跷究，方便控制插件的擴展接入
- 內(nèi)置常見系統(tǒng)(如HDFS、YARN敲霍、HBase)的控制插件揭朝，且可擴展
- 內(nèi)置基于LDAP队贱、文件的用戶同步機制，且可擴展
- 統(tǒng)一的管理界面潭袱，包括策略管理柱嫌、審計查看、插件管理等
本文將從權(quán)限模型屯换、總體架構(gòu)编丘、系統(tǒng)插件三個角度來展開，剖析Ranger如何實現(xiàn)centralized訪問控制彤悔。
權(quán)限模型
訪問權(quán)限無非是定義了“用戶-資源-權(quán)限”這三者間的關(guān)系嘉抓，Ranger基于策略來抽象這種關(guān)系，進而延伸出自己的權(quán)限模型晕窑。為了簡化模型抑片，便于理解，我用以下表達式來描述它：
Policy = Service + List<Resource> + AllowACL + DenyACL
AllowACL = List<AccessItem> allow + List<AccssItem> allowException
DenyACL = List<AccessItem> deny + List<AccssItem> denyException
AccessItem = List<User/Group> + List<AccessType>
接下來從”用戶-資源-權(quán)限*”的角度來詳解上述表達：
用戶：由User或Group來表達杨赤；User代表訪問資源的用戶敞斋，Group代表用戶所屬的用戶組。
資源：由(Service, Resource)二元組來表達疾牲；一條Policy唯一對應(yīng)一個Service植捎，但可以對應(yīng)多個Resource。
權(quán)限：由(AllowACL, DenyACL)二元組來表達阳柔，兩者都包含兩組AccessItem焰枢。而AccessItem則描述一組用戶與一組訪問之間的關(guān)系——在AllowACL中表示允許執(zhí)行，而DenyACL中表示拒絕執(zhí)行舌剂。
下表列出了幾種常見系統(tǒng)的模型實體枚舉值：
關(guān)于權(quán)限這個部分济锄，還有一點沒有解釋清楚：為什么AllowACL和DenyACL需要分別對應(yīng)兩組AccessItem？這是由具體使用場景引出的設(shè)計：
以AllowACL為例霍转，假定我們要將資源授權(quán)給一個用戶組G1拟淮，但是用戶組里某個用戶U1除外，這時只要增加一條包含G1的AccessItem到AllowACL_allow谴忧，同時增加一條包含U1的AccessItem到AllowACL_allowException即可很泊。類似的原因可反推到DenyACL。
既然現(xiàn)在一條Policy有(allow, allowException, deny, denyException)這么四組AccessItem沾谓，那么判斷用戶最終權(quán)限的決策過程是怎樣的委造？
總體來說，這四組AccessItem的作用優(yōu)先級由高到低依次是：
denyException > deny > allowException > allow
訪問決策樹可以用以下流程圖來描述：
這里要對決策下放做一個解釋：如果沒有policy能決策訪問均驶，Ranger可以選擇將決策下放給系統(tǒng)自身的訪問控制層昏兆，比如HDFS的ACL。
總體架構(gòu)
Ranger的總體架構(gòu)如下圖所示妇穴，主要由以下三個組件構(gòu)成：
AdminServer: 以RESTFUL形式提供策略的增刪改查接口爬虱，同時內(nèi)置一個Web管理頁面隶债。
AgentPlugin: 嵌入到各系統(tǒng)執(zhí)行流程中，定期從AdminServer拉取策略跑筝，根據(jù)策略執(zhí)行訪問決策樹死讹，并且定期記錄訪問審計。插件的實現(xiàn)原理將在后文詳細介紹曲梗。
UserSync: 定期從LDAP/File中加載用戶赞警，上報給AdminServer。
系統(tǒng)插件
前文已經(jīng)提到虏两，系統(tǒng)插件主要負責(zé)三件事：
定期從AdminServer拉取策略
根據(jù)策略執(zhí)行訪問決策樹
定期記錄訪問審計
以上執(zhí)行邏輯是通用的愧旦，可由所有系統(tǒng)插件引用，因此剩下的問題是如何把這些邏輯嵌入到各個系統(tǒng)的訪問決策流程中去定罢。目前Ranger里有兩種做法：
-
實現(xiàn)可擴展接口：多數(shù)的系統(tǒng)在實現(xiàn)時都有考慮功能擴展性的問題笤虫，一般會為核心的模塊暴露出可擴展的接口，訪問控制模塊也不例外祖凫。Ranger通過實現(xiàn)訪問控制接口琼蚯，將自己的邏輯嵌入各個系統(tǒng)。下表列出了Ranger插件對幾個常見系統(tǒng)的擴展接口：
- 代碼注入：不排除有少數(shù)系統(tǒng)沒有將訪問控制模塊暴露出擴展點蝙场，這個時候Ranger依賴Java代碼注入機制(java.lang.instrument)來實現(xiàn)邏輯嵌入凌停。以HDFS插件為例粱年，Ranger利用ClassFileTransformer售滤，直接修改HDFS訪問控制類FSPermissionChecker的ClassFile，將checkPermission方法替換成Ranger的自定義實現(xiàn)台诗。
后話
隨著Hadoop生態(tài)圈進軍企業(yè)級市場完箩，數(shù)據(jù)安全逐漸成為關(guān)注焦點。Ranger作為標(biāo)準(zhǔn)化的訪問控制層拉队，引入統(tǒng)一的權(quán)限模型與管理界面弊知，極大地簡化了數(shù)據(jù)權(quán)限的管理。不過粱快，Ranger目前處于孵化項目秩彤，在功能性與穩(wěn)定性上仍然有較大的提升空間，其能否覆蓋更多的系統(tǒng)事哭，一統(tǒng)江湖成為標(biāo)準(zhǔn)漫雷，讓我們拭目以待垄潮。
