大資料許可權授權管理框架：Apache Sentry和Ranger
文章目錄
前言
上篇文章後半部分提到了業界流行的大資料許可權管理框架Apache Sentry和Ranger。二者在功能上具有很高的相似性，但是在具體細節上上篇文章闡述的還不夠細緻。本文筆者來深入淺出地聊聊這兩個框架，以及它們的少許異同點。熟悉掌握使用外部許可權管理框架，並且將它們合理地應用於自身內部大資料元件系統內，無疑將會大大提高內部元件使用的安全性。
Sentry和Ranger的概述
從最源頭開始說起這2個專案，Sentry首先是由Cloudera公司內部開發而來的，初衷是為了讓使用者能夠細粒度的控制Hadoop系統中的資料（這裡主要指HDFS，Hive的資料）。所以Sentry對HDFS，Hive以及同樣由Cloudera開發的Impala有著很好的支援性。
而Ranger則是由於另一家公司Hortonworks所主導。它同樣是做細粒度的許可權控制。但相比較於Sentry而言，它能支援更豐富的元件，包括於 HDFS, Hive, HBase, Yarn, Storm, Knox, Kafka, Solr and NiFi。
這兩個框架在許可權管理時都有運用到基於角色的訪問控制原理（role-based access control，RBAC）。換句話說，當新來一個使用者時，我們賦予它的是一個身份角色，然後這個使用者的執行許可權操作完全由統一的角色本身所允許的一些許可權。基於角色的訪問控制，能夠大大減輕系統對於大資料量使用者的直接ACL控制。
下面我們來細聊著兩大元件的內容。
Sentry
Sentry的架構模型
上文提到過，Sentry在最初發展階段只是對部分元件支援的比較好，沒有像Ranger支援的那麼多。
首先，我們來看Sentry的整體架構
DataEngine指的是具體的資料應用程式，這裡指的是HDFS，Hive和Impala。
Plugin，Plugin程式負責和Sentry Server通訊，做許可權策略資訊的同步。同時在Plugin程式中，包含了認證引擎模組，來做許可權的驗證操作。
Policy metadata，這裡的matadata儲存許可權策略資料，對應的會需要一個外部儲存db。
從另一個角度層面來看Sentry的內部結構
Sentry與Hadoop生態圈元件的整合
Sentry與Hive，HDFS，Impala等元件整合的較好， 結構圖如下圖所示：
從上圖中，我們注意到一個細節，在HDFS裡面多了一個cache層，這個是用來幹嘛的呢？其實為了保持HDFS的許可權與HIve的一致，NameNode的Sentry Plugin程式會定期拉取Hive的Metadata資訊以及Sentry Server上的許可權資訊，並cache起來。這可以說也是為了效能考慮了。
另外地在Sentry Sever中，它還有audit模組，記錄了所有模組的請求訪問記錄。
Ranger
Ranger相比較於Sentry來說，它的功能可以說更加具有通用性。這裡說的通用性在於以下兩點：
- 上層支援的應用元件更多
- 對於控制的資源的型別更多
第一點，前文已經提到過，第二點這裡的資源就不僅僅只有檔案和目錄了這種了，它還可以有表，行以及列的訪問控制。這些都是體現在Ranger的策略資訊裡面的。
Ranger的架構模型
以下是Ranger的架構模型，和Sentry有類似之處。
對於具體的策略控制，由使用者通過admin web ui頁面進行配置。
Ranger的策略配置
對於使用者的ACL控制
我們先來看最簡單的，對於使用者的訪問控制，我們可以設定使用者對於選定的路徑有哪些許可權，策略細節如下：
配置此策略資訊後，系統會對這些使用者做額外判斷處理。
表的行過濾及列處理
小標題這裡我們指的是對Hive的表資料。假設我們有一以下Hive表。
Table: customer
+----+------------+-----------+--------------+---------------+----------------+
| id | name_first | name_last | addr_country | date_of_birth | phone_num |
+----+------------+-----------+--------------+---------------+----------------+
| 1 | Mackenzy | Smith | US | 1993-12-18 | 123-456-7890 |
| 2 | Sherlyn | Miller | US | 1975-03-22 | 234-567-8901 |
| 3 | Khiana | Wilson | US | 1989-08-14 | 345-678-9012 |
| 4 | Jack | Thompson | US | 1962-10-28 | 456-789-0123 |
| 5 | Audrey | Taylor | UK | 1985-01-11 | 12-3456-7890 |
| 6 | Ruford | Walker | UK | 1976-05-19 | 23-4567-8901 |
| 7 | Marta | Lloyd | UK | 1981-07-23 | 34-5678-9012 |
| 8 | Derick | Schneider | DE | 1982-04-17 | 12-345-67890 |
| 9 | Anna | Richter | DE | 1995-09-07 | 23-456-78901 |
| 10 | Raina | Graf | DE | 1999-02-06 | 34-567-89012 |
| 11 | Felix | Lee | CA | 1982-04-17 | 321-654-0987 |
| 12 | Adam | Brown | CA | 1995-09-07 | 432-765-1098 |
| 13 | Lucas | Jones | CA | 1999-02-06 | 543-876-2109 |
| 14 | Yvonne | Dupont | FR | 1982-04-17 | 01-23-45-67-89 |
| 15 | Pascal | Fournier | FR | 1995-09-07 | 23-45-67-89-01 |
| 16 | Ariel | Simon | FR | 1999-02-06 | 34-56-78-90-12 |
+----+------------+-----------+--------------+---------------+----------------+
假設此時我們執行以下查詢語句，我們肯定能查到所有表資料的：
select * from cust.customer
如果此時我們加一個使用者歸屬地的判斷，每個使用者只能查到它所屬那個地域的資料。比如多了以下的使用者關係：
+--------------+---------------+
| Group name | Users |
+--------------+---------------+
| us-employees | john,scott |
| uk-employees | mary,adam |
| de-employees | drew,alice |
+--------------+---------------+
在Ranger的頁面配置效果如下圖所示：
然後我們以john使用者身份去查，查出的記錄所屬地域就只會是US上的了，不會受全部的資料了。
[john@localhost ~]$ beeline -u jdbc:hive2://localhost.localdomain:10000/cust
0: jdbc:hive2://localhost.localdomain:10000> select * from cust.customer;
+-----+-------------+------------+---------------+----------------+--------------+
| id | name_first | name_last | addr_country | date_of_birth | phone_num |
+-----+-------------+------------+---------------+----------------+--------------+
| 1 | Mackenzy | Smith | US | 1993-12-18 | 123-456-7890 |
| 2 | Sherlyn | Miller | US | 1975-03-22 | 234-567-8901 |
| 3 | Khiana | Wilson | US | 1989-08-14 | 345-678-9012 |
| 4 | Jack | Thompson | US | 1962-10-28 | 456-789-0123 |
+-----+-------------+------------+---------------+----------------+--------------+
對於列處理，Ranger支援對部分敏感欄位實施遮掩處理，比如下面是對電話號碼的處理
+
-----+-------------+------------+---------------+----------------+--------------+
| id | name_first | name_last | addr_country | date_of_birth | phone_num |
+-----+-------------+------------+---------------+----------------+--------------+
| 1 | Mackenzy | NULL | US | 1993-01-01 | xxx-xxx-7890 |
| 2 | Sherlyn | NULL | US | 1975-01-01 | xxx-xxx-8901 |
| 3 | Khiana | NULL | US | 1989-01-01 | xxx-xxx-9012 |
+-----+-------------+------------+---------------+----------------+--------------+
Ranger的Policy的靈活性
通過的Policy策略還有許多靈活的特性，包括它還能支援基於Tag的策略控制，有了Tag後，就無需考慮元件的差別了。另外還有condition的條件的新增控制，這些也都是由管理員使用者人工控制的。
同樣的，Ranger Plugin程式會拉取策略資料在本地，如果說Ranger admin server臨時不可用了，也不會影響策略實際的執行認證。
以上就是本文的全部內容了，兩個框架非常類似，真要說區別的話，Sentry在於它對於Hive等相關元件支援整合的比較好（也和這個專案本身發展初期設計決定），而Ranger在於它更通用化的支援和更加豐富的策略控制。
引用
[1].https://cwiki.apache.org/confluence/display/RANGER/Row-level+filtering+and+column-masking+using+Apache+Ranger+policies+in+Apache+Hive?preview=/65868896/65868900/rowFilter-usecase-1.jpg
[2].https://www.linkedin.com/pulse/apache-ranger-vs-sentry-mythily-rajavelu/
[3].https://cwiki.apache.org/confluence/display/SENTRY/Sentry+Tutorial
[4].https://www.cnblogs.com/qiuyuesu/p/6774520.html
