cdh版本的hadoop在對資料安全上的處理通常採用Kerberos+Sentry的結構。
kerberos主要負責平臺使用者的許可權管理，sentry則負責資料的許可權管理。

下面我們來依次瞭解一下：
Kerberos包含一箇中心節點和若干從節點，所有節點的Kerberos認證資訊都要與中心節點的規則配置檔案/etc/krb5.conf保持一致。安全認證均需通過中心節點，配置了安全認證的使用者可以登入到叢集內的 機器。
Kerberos的配置檔案有兩個：
1、/var/kerberos/krb5kdc/kdc.conf:包括KDC的配置資訊。預設放在 /usr/local/var/krb5kdc。或者通過覆蓋KRB5_KDC_PROFILE環境變數修改配置檔案位置。
2、/etc/krb5.conf:包含Kerberos的配置資訊
Kerberos的管理物件稱為principal（規則）, 與HDFS中的使用者一一對應。一般我們將hdfs設定為principal的管理員，它可以建立刪除其他的principal,還可以生成其他成員的keytab。keytab是每個principal對應的金鑰檔案，當kerberos認證使用keytab時，可以不需要輸入密碼，類似於SSH的信任機制。
當我們配置Kerberos的時候，系統會預設生成使用者，格式一般為【使用者名稱/hostname@domain_name】，一般情況下我們使用自己定義的使用者，不要對系統生成的使用者加以修改。
輸入kadmin.local 進入Kerberos的互動命令列。
生成keytab: xst –k testuser.keytab [email protected],將對應的keytab拷貝至其他位置或伺服器，則相應的節點則可以通過testuser的principal連線進HDFS.
登入到管理員賬戶: 如果在本機上，可以通過kadmin.local直接登入。其它機器的，先使用kinit進行驗證。
kadmin.local  kinit admin/adminkadmin
增刪改查賬戶:在管理員的狀態下使用addprinc,delprinc,modprinc,listprincs命令。使用？可以列出所有的命令。
kamdin:addprinc -randkey hdfs/hadoop1kamdin:delprinc hdfs/hadoop1kamdin:listprincs命令
生成keytab:使用xst命令或者ktadd命令
kadmin:xst -k /xxx/xxx/kerberos.keytab hdfs/hadoop1
建立一個新的principal: addprinc [email protected],並輸入密碼
使用者操作
檢視當前的認證使用者:klist
認證使用者:kinit -kt /xx/xx/kerberos.keytab hdfs/hadoop1
刪除當前的認證的快取: kdestroy

Apache Sentry的目標是實現授權管理，它是一個策略引擎，被資料處理工具用來驗證訪問許可權。它也是一個高度擴充套件的模組，可以支援任何的資料模型。當前，它支援Apache Hive和Cloudera Impala的關係資料模型，對hue的資料許可權控制也有應用。
Sentry的管理物件有三個，資料庫，角色，和組。資料庫是在hive中建立的資料庫，角色在impala中建立，而組是作業系統的使用者組。
Sentry的許可權管理操作，都通過impala語句完成。只有啟動了sentry服務，impala服務才能正常執行。
使用impala-shell進入互動終端：
show roles列出所有的角色
show databases列出所有的資料庫
create role test_role建立角色
drop role test_role刪除角色
可以直接輸入show命令會提示可以跟接的關鍵字
grant all on database ana_clientact to role admin_role 將一個數據庫賦權給一個角色
revoke all on database from role admin_role取消許可權
如果資料庫中的是外部表，需要同時給角色賦予uri許可權：
grant all on uri 'hdfs://192.168.2.121:8020/mydata' to role admin_role
列出某角色的許可權：show grant role admin_role
將角色賦給一個組：grant role admin_role to group hive
完成以上操作以後，使用者組即具有了相應資料庫的操作許可權。此時需要執行invalidate metadata操作，才會生效。
當一個新的作業系統使用者加入這個使用者組，使用者即具有對應的資料庫許可權。反之，將使用者從這個組中去掉，使用者對資料庫的操作許可權即消失。
新建使用者組時要保證叢集內組和使用者保持一致。

在HUE中配置許可權
在HUE中，使用者的許可權是分為兩個層次實現的，一個層次是HUE平臺各模組的許可權，這個通過HUE中組和許可權實現的，另一個層次是HUE訪問hive,impala資料庫的許可權，這個和sentry是統一的，HUE中的使用者和作業系統中的使用者一一對映，HUE通過尋找相同使用者名稱的作業系統使用者來確定對應的sentry許可權。
這裡需要注意一點，HUE中的組和作業系統的組沒有關係，HUE中的組只繫結HUE平臺自己的許可權。

Apache Sentry 是Cloudera公司釋出的一個Hadoop開源元件，截止目前還是Apache的孵化專案，它提供了細粒度級、基於角色的授權以及多租戶的管理模式。Sentry當前可以和Hive/Hcatalog、Apache Solr 和Cloudera Impala整合，未來會擴充套件到其他的Hadoop元件，例如HDFS和HBase。

特性

Apache Sentry為Hadoop使用者提供了以下便利：

• 能夠在Hadoop中儲存更敏感的資料
• 使更多的終端使用者擁有Hadoop資料訪問權
• 建立更多的Hadoop使用案例
• 構建多使用者應用程式
• 符合規範（例如SOX，PCI，HIPAA，EAL3）

在Sentry誕生之前，對於授權有兩種備選解決方案： 粗粒度級的HDFS授權 和 諮詢授權 ，但它們並不符合典型的規範和資料安全需求，原因如下：

• 粗粒度級的HDFS授權 ：安全訪問和授權的基本機制被HDFS檔案模型的粒度所限制。五級授權是粗粒度的，因為沒有對檔案內資料的訪問控制：使用者要麼可以訪問整個檔案，要麼什麼都看不到。另外，HDFS許可權模式不允許多個組對同一資料集有不同級別的訪問許可權。
• 諮詢授權 ：諮詢授權在Hive中是一個很少使用的機制，旨在使使用者能夠自我監管，以防止意外刪除或重寫資料。這是一種“自服務”模式，因為使用者可以為自己授予任何許可權。因此，一旦惡意使用者通過認證，它不能阻止其對敏感資料的訪問。

通過引進Sentry，Hadoop目前可在以下方面滿足企業和政府使用者的RBAC需求：

• 安全授權 ：Sentry可以控制資料訪問，並對已通過驗證的使用者提供資料訪問特權。
• 細粒度訪問控制 ：Sentry支援細粒度的Hadoop資料和元資料訪問控制。在Hive和Impala中Sentry的最初發行版本中，Sentry在伺服器、資料庫、表和檢視範圍提供了不同特權級別的訪問控制，包括查詢、插入等，允許管理員使用檢視限制對行或列的訪問。管理員也可以通過Sentry和帶選擇語句的檢視或UDF，根據需要在檔案內遮蔽資料。
• 基於角色的管理 ：Sentry通過基於角色的授權簡化了管理，你可以輕易將訪問同一資料集的不同特權級別授予多個組。
• 多租戶管理 ：Sentry允許為委派給不同管理員的不同資料集設定許可權。在Hive/Impala的情況下，Sentry可以在資料庫/schema級別進行許可權管理。
• 統一平臺 ：Sentry為確保資料安全，提供了一個統一平臺，使用現有的Hadoop Kerberos實現安全認證。同時，通過Hive或Impala訪問資料時可以使用同樣的Sentry協議。未來，Sentry協議會被擴充套件到其它元件。

如何工作

Apache Sentry的目標是實現授權管理，它是一個策略引擎，被資料處理工具用來驗證訪問許可權。它也是一個高度擴充套件的模組，可以支援任何的資料模型。當前，它支援Apache Hive和Cloudera Impala的關係資料模型，以及Apache中的有繼承關係的資料模型。

Sentry提供了定義和持久化訪問資源的策略的方法。目前，這些策略可以儲存在檔案裡或者是能使用RPC服務訪問的資料庫後端儲存裡。資料訪問工具，例如Hive，以一定的模式辨認使用者訪問資料的請求，例如從一個表讀一行資料或者刪除一個表。這個工具請求Sentry驗證訪問是否合理。Sentry構建請求使用者被允許的許可權的對映並判斷給定的請求是否允許訪問。請求工具這時候根據Sentry的判斷結果來允許或者禁止使用者的訪問請求。

Sentry授權包括以下幾種角色：

• 資源 。可能是 Server 、 Database 、 Table 、或者 URL （例如：HDFS或者本地路徑）。Sentry1.5中支援對 列 進行授權。
• 許可權 。授權訪問某一個資源的規則。
• 角色 。角色是一系列許可權的集合。
• 使用者和組 。一個組是一系列使用者的集合。Sentry 的組對映是可以擴充套件的。預設情況下，Sentry使用Hadoop的組對映（可以是作業系統組或者LDAP中的組）。Sentry允許你將使用者和組進行關聯，你可以將一系列的使用者放入到一個組中。Sentry不能直接給一個使用者或組授權，需要將許可權授權給角色，角色可以授權給一個組而不是一個使用者。

架構

下面是Sentry架構圖，圖片來自《 Apache Sentry architecture overview 》。

Sentry的體系結構中有三個重要的元件：一是Binding；二是Policy Engine；三是Policy Provider。

Binding

Binding實現了對不同的查詢引擎授權，Sentry將自己的Hook函式插入到各SQL引擎的編譯、執行的不同階段。這些Hook函式起兩大作用：一是起過濾器的作用，只放行具有相應資料物件訪問許可權的SQL查詢；二是起授權接管的作用，使用了Sentry之後，grant/revoke管理的許可權完全被Sentry接管，grant/revoke的執行也完全在Sentry中實現；對於所有引擎的授權資訊也儲存在由Sentry設定的統一的資料庫中。這樣所有引擎的許可權就實現了集中管理。

Policy Engine

這是Sentry授權的核心元件。Policy Engine判定從binding層獲取的輸入的許可權要求與服務提供層已儲存的許可權描述是否匹配。

Policy Provider

Policy Provider負責從檔案或者資料庫中讀取出原先設定的訪問許可權。Policy Engine以及Policy Provider其實對於任何授權體系來說都是必須的，因此是公共模組，後續還可服務於別的查詢引擎。

基於檔案的提供者使用的是ini格式的檔案儲存元資料資訊，這個檔案可以是一個本地檔案或者HDFS檔案。下面是一個例子：

1. [groups]

2. # Assigns each Hadoop group to its set of roles

3. manager = analyst_role, junior_analyst_role

4. analyst = analyst_role

5.  

6. admin = admin_role

7. [roles]

8. analyst_role = server=server1->db=analyst1, \

9. server=server1->db=jranalyst1->table=*->action=select, \

10. server=server1->uri=hdfs://ha-nn-uri/landing/analyst1, \

11. server=server1->db=default->table=tab2

12. # Implies everything on server1.

13. admin_role = server=server1

14.  

基於檔案的方式不易於使用程式修改，在修改過程中會存在資源競爭，不利於維護。Hive和Impala需要提供工業標準的SQL介面來管理授權策略，要求能夠使用程式設計的方式進行管理。

Sentry策略儲存和服務將角色和許可權以及組合角色的對映持久化到一個關係資料庫並提供程式設計的API介面方便建立、查詢、更新和刪除。這允許Sentry的客戶端並行和安全地獲取和修改許可權。

Sentry策略儲存可以使用很多後端的資料庫，例如MySQL、Postgres等等，它使用ORM庫DataNucleus來完成持久化操作。Sentry支援kerberos認證，也可以擴充套件程式碼支援其他認證方式。

使用

和Hive整合

Sentry策略引擎通過hook的方式插入到hive中，hiveserver2在查詢成功編譯之後執行這個hook。

這個hook獲得這個查詢需要以讀和寫的方式訪問的物件，然後Sentry的Hive binding基於SQL授權模型將他們轉換為授權的請求。

策略維護：

策略維護包括兩個步驟。在查詢編譯期間，hive呼叫Sentry的授權任務工廠來生產會在查詢過程中執行的Sentry的特定任務行。這個任務呼叫Sentry儲存客戶端傳送RPC請求給Sentry服務要求改變授權策略。

和HCatalog整合

Sentry通過pre-listener hook整合到Hive Metastore。metastore在執行metadata維護請求之前執行這個hook。metastore binding為提交給metastore和HCatalog客戶端的metadata修改請求建立一個Sentry授權請求。

一、Sentry CDH配置
安裝Sentry
使用Cloudera Manager來安裝，非常簡單，需要注意的是安裝前要在/opt/cloudera/parcels/CDH/jars目錄下放入MySQL的驅動包。

新增服務 –> Sentry

Sentry Database Create:

#為Sentry建資料庫sentry
mysql>create database sentry DEFAULT CHARSET utf8 COLLATE utf8_general_ci;
1
2

Sentry整合其它元件
Sentry 整合其它元件

補充：

新增 Hive, Impala, HUE, HUE 預設超級管理員組到 Sentry admin 組

在 Clouder Manager 對 Sentry 進行配置，修改 Admin Group，新增hive，impala， hue，admin(hue的預設超級管理員)，重啟 Sentry 服務。

新增admin組的原因是，我們使用admin登入Hue，然後對角色許可權進行控制。當然使用上面新增的hive、impala、hue也可以。

二、Sentry授權步驟
1.在所有節點的機器上建立使用者和組

2.在hue建使用者和組，這裡的使用者和組要求和第一部linux的使用者和組是一樣

3.登入管理員使用者，給其他使用者付許可權

4.建role，和給role付許可權

如下圖，點選Sentry進入編輯頁面，選上test1使用者

點選右側的 addrole

填角色名稱，角色所屬的組，和角色的許可權

5.用對應的test1登入，可以看到自己許可權的資料表

四、linux加使用者組
# groupadd  g1

# useradd   u1

# usermod -g   g1 u1