前言
本篇簡單介紹一下業(yè)界流行的大數(shù)據(jù)權(quán)限管理框架Apache Sentry和Ranger。
- Apache Sentry
Sentry是由Cloudera公司內(nèi)部開發(fā)而來的,初衷是為了讓用戶能夠細粒度的控制Hadoop系統(tǒng)中的數(shù)據(jù)(這里主要指HDFS,Hive的數(shù)據(jù))。所以Sentry對HDFS,Hive以及同樣由Cloudera開發(fā)的Impala有著很好的支持性。 - Apache Ranger
Ranger則是由于另一家公司Hortonworks所主導(dǎo)。它同樣是做細粒度的權(quán)限控制。但相比較于Sentry而言,它能支持更豐富的組件,包括于 HDFS, Hive, HBase, Yarn, Storm, Knox, Kafka, Solr and NiFi。
這兩個框架在權(quán)限管理時都有運用到基于角色的訪問控制原理(role-based access control,RBAC)。換句話說,當(dāng)新來一個用戶時,我們賦予它的是一個身份角色,然后這個用戶的執(zhí)行權(quán)限操作完全由統(tǒng)一的角色本身所允許的一些權(quán)限?;诮巧脑L問控制,能夠大大減輕系統(tǒng)對于大數(shù)據(jù)量用戶的直接ACL控制。
下面就簡單介紹一下兩種權(quán)限授權(quán)管理框架:
Sentry
Sentry的架構(gòu)模型

- DataEngine指的是具體的數(shù)據(jù)應(yīng)用程序,這里指的是HDFS,Hive和Impala。
- Plugin,Plugin程序負責(zé)和Sentry Server通信,做權(quán)限策略信息的同步。同時在Plugin程序中,包含了認證引擎模塊,來做權(quán)限的驗證操作。
- Policy metadata,這里的matadata存儲權(quán)限策略數(shù)據(jù),對應(yīng)的會需要一個外部存儲db。
從另一個角度層面來看Sentry的內(nèi)部結(jié)構(gòu)

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

從上圖中,我們注意到一個細節(jié),在HDFS里面多了一個cache層,這個是用來干嘛的呢?其實為了保持HDFS的權(quán)限與HIve的一致,NameNode的Sentry Plugin程序會定期拉取Hive的Metadata信息以及Sentry Server上的權(quán)限信息,并cache起來。這可以說也是為了性能考慮了。
另外地在Sentry Sever中,它還有audit模塊,記錄了所有模塊的請求訪問記錄。
Ranger
Ranger相比較于Sentry來說,它的功能可以說更加具有通用性。這里說的通用性在于以下兩點:
- 上層支持的應(yīng)用組件更多
- 對于控制的資源的類型更多
第一點,前文已經(jīng)提到過,第二點這里的資源就不僅僅只有文件和目錄了這種了,它還可以有表,行以及列的訪問控制。這些都是體現(xiàn)在Ranger的策略信息里面的。
Ranger的架構(gòu)模型

對于具體的策略控制,由用戶通過admin web ui頁面進行配置。
Ranger的策略配置
對于用戶的ACL控制
我們先來看最簡單的,對于用戶的訪問控制,我們可以設(shè)置用戶對于選定的路徑有哪些權(quán)限,策略細節(jié)如下:

配置此策略信息后,系統(tǒng)會對這些用戶做額外判斷處理。
表的行過濾及列處理
假設(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è)此時我們執(zhí)行以下查詢語句,我們肯定能查到所有表數(shù)據(jù)的:
select * from cust.customer
如果此時我們加一個用戶歸屬地的判斷,每個用戶只能查到它所屬那個地域的數(shù)據(jù)。比如多了以下的用戶關(guān)系:
+--------------+---------------+
| Group name | Users |
+--------------+---------------+
| us-employees | john,scott |
| uk-employees | mary,adam |
| de-employees | drew,alice |
+--------------+---------------+
在Ranger的頁面配置效果如下圖所示:

然后我們以john用戶身份去查,查出的記錄所屬地域就只會是US上的了,不會受全部的數(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 |
+-----+-------------+------------+---------------+----------------+--------------+
對于列處理,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程序會拉取策略數(shù)據(jù)在本地,如果說Ranger admin server臨時不可用了,也不會影響策略實際的執(zhí)行認證。
總結(jié):
兩個框架非常類似,真要說區(qū)別的話,Sentry在于它對于Hive等相關(guān)組件支持集成的比較好(也和這個項目本身發(fā)展初期設(shè)計決定),而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