Sentry的架構
內部架構
核心就是規則引擎以及Metadata Store；記錄格式有兩種，一種policy file記錄授權內容，另外一種是通過命令方式進行授權；前者記錄在策略文件中，保存形式是hdfs的一個文件；后者則是記錄在數據庫中，保存在關系型數據庫中（通常和hive的metadata保存在一個MySQL實例中）。
調用模型
Sentry Server對外公開PRC端口以及Web 服務兩種接口（以PRC為主），供外界調用；在通過cloudera安裝sentry的時候，其實已經把Sentry Server以及Sentry Client安裝好了（測試集群只是有hive，默認hive在安裝完了sentry之后即和sentry綁定）；
Sentry Client
Client種類
Sentry的Hadoop ACL Sync
這些客戶端中，HDFS的client比較特殊；因為已經在hive中設置了sentry權限，hive本身就是訪問hdfs文件，為什么還要在hdfs層再做權限控制呢？這是因為除了hive可以直接訪問hdfs的文件之外，還有Map-Reduce程序，pig，spark等可以訪問hdfs，所以只是在hive層面去做是不夠的；
在cloudera中可以通過配置hdfs的Enable Sentry Synchronization選項來實現hive權限直接下放；比如你在hive中配置了bd這個用戶可以訪問sentry_test這個表；那么用bd這個用戶在命令行中就可以訪問/user/hive/warehouse/sentry_test目錄；但是不能訪問同級的其他目錄以及上級目錄。
Hdfs在這里的權限控制是在首先是走sentry的權限控制，如果Sentry中沒有配置，才是走文件的權限控制。
1.1.1.1
Sentry權限控制
Sentry的用戶映射源
三種：
- Kerberos;
- LDAP;
- Linux User/Group；官網文檔描述的第三種是和hadoop的用戶對應；但是真實測試中發現如果是一個hadoop存在但是Linux系統中不存在的用戶，無法授權成功；所以這里我認為還是Linux自己的用戶和組；
Sentry的授權
是標准的基於角色的授權（Role Base Access Control， RBAC）。
- 資源和權限綁定，權限在Sentry中分為三種：Select，Insert，ALL；
- 權限和角色綁定；
- 角色和用戶綁定（用戶來自於上面提到的三種）；
Sentry權限控制的實現
在Build和Plan之間，添加鈎子，來進行權限驗證。
參考文檔：
https://cwiki.apache.org/confluence/display/SENTRY/Documentation