前言

本篇簡單介紹一下業(yè)界流行的大數(shù)據(jù)權(quán)限管理框架Apache Sentry和Ranger。

• Apache Sentry
  Sentry是由Cloudera公司內(nèi)部開發(fā)而來的，初衷是為了讓用戶能夠細(xì)粒度的控制Hadoop系統(tǒng)中的數(shù)據(jù)（這里主要指HDFS，Hive的數(shù)據(jù)）。所以Sentry對(duì)HDFS，Hive以及同樣由Cloudera開發(fā)的Impala有著很好的支持性。
• Apache Ranger
  Ranger則是由于另一家公司Hortonworks所主導(dǎo)。它同樣是做細(xì)粒度的權(quán)限控制。但相比較于Sentry而言，它能支持更豐富的組件，包括于 HDFS, Hive, HBase, Yarn, Storm, Knox, Kafka, Solr and NiFi。

這兩個(gè)框架在權(quán)限管理時(shí)都有運(yùn)用到基于角色的訪問控制原理（role-based access control，RBAC）。換句話說，當(dāng)新來一個(gè)用戶時(shí)，我們賦予它的是一個(gè)身份角色，然后這個(gè)用戶的執(zhí)行權(quán)限操作完全由統(tǒng)一的角色本身所允許的一些權(quán)限?；诮巧脑L問控制，能夠大大減輕系統(tǒng)對(duì)于大數(shù)據(jù)量用戶的直接ACL控制。

下面就簡單介紹一下兩種權(quán)限授權(quán)管理框架：

Sentry

Sentry的架構(gòu)模型

• DataEngine指的是具體的數(shù)據(jù)應(yīng)用程序，這里指的是HDFS，Hive和Impala。
• Plugin，Plugin程序負(fù)責(zé)和Sentry Server通信，做權(quán)限策略信息的同步。同時(shí)在Plugin程序中，包含了認(rèn)證引擎模塊，來做權(quán)限的驗(yàn)證操作。
• Policy metadata，這里的matadata存儲(chǔ)權(quán)限策略數(shù)據(jù)，對(duì)應(yīng)的會(huì)需要一個(gè)外部存儲(chǔ)db。

從另一個(gè)角度層面來看Sentry的內(nèi)部結(jié)構(gòu)

Sentry與Hive，HDFS，Impala等組件集成的較好， 結(jié)構(gòu)圖如下圖所示：

從上圖中，我們注意到一個(gè)細(xì)節(jié)，在HDFS里面多了一個(gè)cache層，這個(gè)是用來干嘛的呢？其實(shí)為了保持HDFS的權(quán)限與HIve的一致，NameNode的Sentry Plugin程序會(huì)定期拉取Hive的Metadata信息以及Sentry Server上的權(quán)限信息，并cache起來。這可以說也是為了性能考慮了。

另外地在Sentry Sever中，它還有audit模塊，記錄了所有模塊的請(qǐng)求訪問記錄。

Ranger

Ranger相比較于Sentry來說，它的功能可以說更加具有通用性。這里說的通用性在于以下兩點(diǎn)：

• 上層支持的應(yīng)用組件更多
• 對(duì)于控制的資源的類型更多

第一點(diǎn)，前文已經(jīng)提到過，第二點(diǎn)這里的資源就不僅僅只有文件和目錄了這種了，它還可以有表，行以及列的訪問控制。這些都是體現(xiàn)在Ranger的策略信息里面的。

Ranger的架構(gòu)模型

對(duì)于具體的策略控制，由用戶通過admin web ui頁面進(jìn)行配置。

Ranger的策略配置

對(duì)于用戶的ACL控制

我們先來看最簡單的，對(duì)于用戶的訪問控制，我們可以設(shè)置用戶對(duì)于選定的路徑有哪些權(quán)限，策略細(xì)節(jié)如下：

配置此策略信息后，系統(tǒng)會(huì)對(duì)這些用戶做額外判斷處理。

表的行過濾及列處理

假設(shè)我們有一以下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 |
+----+------------+-----------+--------------+---------------+----------------+

假設(shè)此時(shí)我們執(zhí)行以下查詢語句，我們肯定能查到所有表數(shù)據(jù)的：

select * from cust.customer

如果此時(shí)我們加一個(gè)用戶歸屬地的判斷，每個(gè)用戶只能查到它所屬那個(gè)地域的數(shù)據(jù)。比如多了以下的用戶關(guān)系：

+--------------+---------------+
| Group name   | Users         |
+--------------+---------------+
| us-employees | john,scott    |
| uk-employees | mary,adam     |
| de-employees | drew,alice    |
+--------------+---------------+

在Ranger的頁面配置效果如下圖所示：

然后我們以john用戶身份去查，查出的記錄所屬地域就只會(huì)是US上的了，不會(huì)受全部的數(shù)據(jù)了。

[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 |
+-----+-------------+------------+---------------+----------------+--------------+

對(duì)于列處理，Ranger支持對(duì)部分敏感字段實(shí)施遮掩處理，比如下面是對(duì)電話號(hào)碼的處理

+-----+-------------+------------+---------------+----------------+--------------+
| 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程序會(huì)拉取策略數(shù)據(jù)在本地，如果說Ranger admin server臨時(shí)不可用了，也不會(huì)影響策略實(shí)際的執(zhí)行認(rèn)證。

總結(jié)：

兩個(gè)框架非常類似，真要說區(qū)別的話，Sentry在于它對(duì)于Hive等相關(guān)組件支持集成的比較好（也和這個(gè)項(xiàng)目本身發(fā)展初期設(shè)計(jì)決定），而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