要說清楚這個問題，還得從大資料平台安全體系的四個層次說起：外圍安全、資料安全、通路安全以及通路行為監控；如下圖所示；
外圍安全技術多指傳統意義上提到的網絡安全技術，如防火牆，登陸認證等；
資料安全從狹義上說包括對使用者資料的加解密，又可細分為存儲加密和傳輸加密；還包括使用者資料的脫敏，脫敏可以看做“輕量級”的資料加密。如某人的生日為“2014-12-12”，脫敏後的資料為“2014-x-x”。資料的輪廓依然存在，但已無法精确定位數值。脫敏的程度越高資料可辨認度越低。上述的例子還可脫敏為“x-x-x”，相當于完全對外屏蔽該資訊。
通路安全主要是對使用者的授權進行管理。linux/unix系統中使用者-組的讀、寫、執行權限管理堪稱其中的經典模型。hdfs對這一概念進行了擴充，形成了更加完備的acl體系；另外随着大資料的應用的普及和深入，檔案内部資料通路權限差異化的需求也變得越來越重要；
通路行為監控多指記錄使用者對系統的通路行為：如檢視哪個檔案；運作了哪些sql查詢；通路行為監控一方面為了進行實時報警，迅速處置非法或者危險的通路行為；另一方面為了事後調查驗證，從長期的資料通路行為中分析定位特定的目的。
在這四個安全的層次中，第三層同上層業務的關系最為直接：應用程式的多租戶，分權限通路控制都直接依賴這一層的技術實作。
在上述的第三層中，hadoop生态圈長久以來一直沿用linux/unix系統的授權管理模型，将檔案的通路權限分為讀-寫兩種權限（hdfs上沒有可執行檔案的概念），将權限的所有者劃分為三個大類：擁有者（owner），所在組（group），以及其他人（other）。這種模型限制權限的所有者隻能有三類。如果試圖增加一個新的“組”，并設定該組的使用者擁有不同于owner，group或other的權限，現有的linux/unix授權模型是無法優雅地解決這個問題的。
舉例來說明上述狀況：假設有一個銷售部門，部門經理manager具有修改銷售資料sales_data的權利；銷售部門的成員具有檢視sales_data的權利，銷售部門以外的人無法看到銷售資料sales_data。那麼對于銷售資料sales_data的授權如下所示：
-rw-r----- 3 manager sales 0 2015-01-25 18:51 sales_data
後來該銷售部門擴充了人員，又來兩個銷售經理，一個叫manager1，另一個叫manager2。這兩個銷售經理也被允許修改銷售資料。這種情況下，manager1和manager2隻能使用一個新賬号manager_account，然後使該賬号能夠使用setuid對sales_data進行修改。這使得對同一份資料的權限管理變得複雜而不容易維護。
由于上述問題的存在，hadoop2.4.0中添加了對hdfs acl（access control lists）的支援。這一新特性很好地解決了上述的問題。然而随着hadoop在企業中廣泛地應用，越來越多的業務場景要求大資料通路控制的粒度也不再局限在檔案級别，而是更加細緻地限制檔案内部的資料哪些能被讀寫，哪些隻能被讀，哪些完全不允許被通路。對于基于sql的大資料引擎來說，資料通路不止要到表粒度，更要精确到行列級别。
hive是早期将進階查詢語言sql引入hadoop平台的引擎之一，早期的hive伺服器程序被稱作hiveserver1；hiveserver1既不支援處理并行的多個連接配接，又不支援通路授權控制；後來這兩個問題在hiveserver2上被解決，hiveserver2能夠使用grant/revoke語句來限制使用者對資料庫、表、視圖的通路權限，行列權限的控制是通過生成視圖來實作的；但hiveserver2的授權管理體系被認為存在問題，那就是任何通過認證登陸的使用者都能夠為自己增加對任何資源的通路權限。也就是說hiveserver2提供的不是一種安全的授權體系，hiveserver2的授權體系是為防止正常使用者誤操作而提供保障機制；不是為保護敏感資料的安全性而設計的。然而這些更多的是某些公司的說辭，事實上hiveserver2自身的安全體系也在逐漸完善，上述問題也在快速修複中。
但授權管理其實不止是hive需要，其他的查詢引擎也迫切需要這些技術來完善和規範應用程式對資料的通路。對于細粒度授權管理的實作，很大一部分功能在各引擎之間是可以公用的，是以獨立實作的授權管理工具是非常必要的。
在這樣的背景下，cloudera公司的一些開發者利用hiveserver2中現有的授權管理模型，擴充并細化了很多細節，完成了一個相對具有使用價值的授權管理工具sentry，下圖是sentry與hiveserver2中的授權管理模型的對比：
sentry的很多基本模型和設計思路都來源于hiveserver2，但在其基礎之上加強了rbac的概念。在sentry中，所有的權限都隻能授予角色，當角色被挂載到使用者組的時候，該組内的使用者才具有相應的權限。權限à角色à使用者組à使用者，這一條線的映射關系在sentry中顯得尤為清晰，這條線的映射顯示了一條權限如何能最後被一個使用者所擁有；從權限到角色，再到使用者組都是通過grant/revoke的sql語句來授予的。從“使用者組”到能夠影響“使用者”是通過hadoop自身的使用者-組映射來實作的。hadoop提供兩種映射：一種是本地伺服器上的linux/unix使用者到所在組的映射；另一種是通過ldap實作的使用者到所屬組的映射；後者對于大型系統而言更加适用，因為具有集中配置，易于修改的好處。
sentry将hiveserver2中支援的資料對象從資料庫/表/視圖擴充到了伺服器，uri以及列粒度。雖然列的權限控制可以用視圖來實作，但是對于多使用者，表數量巨大的情況，視圖的方法會使得給視圖命名變得異常複雜；而且使用者原先寫的針對原表的查詢語句，這時就無法直接使用，因為視圖的名字可能與原表完全不同。
目前sentry1.4能夠支援的授權級别還局限于select，insert，all這三個級别，但後續版本中已經能夠支援到與hiveserver2現有的水準。sentry來源于hiveserver2中的授權管理模型，但卻不局限于隻管理hive，而希望能管理impala, solr等其他需要授權管理的查詢引擎，sentry的架構圖如下所示：
sentry的體系結構中有三個重要的元件：一是binding；二是policy engine；三是policy provider。
binding實作了對不同的查詢引擎授權，sentry将自己的hook函數插入到各sql引擎的編譯、執行的不同階段。這些hook函數起兩大作用：一是起過濾器的作用，隻放行具有相應資料對象通路權限的sql查詢；二是起授權接管的作用，使用了sentry之後，grant/revoke管理的權限完全被sentry接管，grant/revoke的執行也完全在sentry中實作；對于所有引擎的授權資訊也存儲在由sentry設定的統一的資料庫中。這樣所有引擎的權限就實作了集中管理。
policy engine判定輸入的權限要求與已儲存的權限描述是否比對，policy provider負責從檔案或者資料庫中讀取出原先設定的通路權限。policy engine以及policy provider其實對于任何授權體系來說都是必須的，是以是公共子產品，後續還可服務于别的查詢引擎。
大資料平台上細粒度的通路權限控制各家都在做，當然平台廠商方面主導的還是cloudera和hortonworks兩家，cloudera主推sentry為核心的授權體系；hortonwork一方面靠對開源社群走向得把控，另一方面靠收購的xa secure。無論今後兩家公司對大資料平台市場的影響力如何變化，大資料平台上的細粒度授權通路都值得我們去學習。
原文釋出時間：2015-02-04
本文來自雲栖合作夥伴“linux中國”