HDFS

HDFS的許可權系統和普通linux的許可權系統一樣 , 每個檔案或者資料夾都有三種許可權: 擁有者, 相關組和其他人. 

同時HDFS也支援ACL的許可權機制, ACL是基礎的許可權機制的擴充版, 它豐富了基礎的許可權機制裡"其他人"的許可權. 可以為"其他人"指定 fine-grained的許可權.

hdfs dfs -setfacl -m group:execs:r-- /sales-data
hdfs dfs -getfacl /sales-data

hdfs的超級使用者是namenode程序使用的使用者。更確切的說，就是你啟動namenode那麼你就是超級使用者。超級使用者的許可權檢查永遠不會失敗，所以可以幹任何事情。沒有固定的超級使用者，當誰啟動namenode誰就是超級使用者。HDFS的超級使用者不是namenode主機的超級使用者，沒有必要，但是他是所有叢集的超級使用者。此外,HDFS的實驗者在個人工作站,方便就安裝的超級使用者沒有任何配置。

此外管理員可以通過配置引數確定一個高階的組，這個組的成員也是超級使用者。

Oozie

ProxyUser

在關係型資料庫中很多資料庫的任務要定期執行, 比如sqlserver中的job, 這些任務執行時很可能需要特定的檔案permission, 所以需要以特定的賬戶來執行, 這就是proxy的一個典型使用場景. 在Hadoop中Oozie就經常有這樣的需求.

在Hadoop的core-site.xml中配置proxy:

<property>
    <name>hadoop.proxyuser.oozie.hosts</name>
    <value>*</value>
</property>

<property>
    <name>hadoop.proxyuser.oozie.groups</name>
    <value>*</value>
</property>
 

讓oozie伺服器可以在任意的主機上, 扮演任意組的使用者.

比如使用者A在某臺伺服器上提交了一個oozie任務, 如果沒有proxy,預設情況oozie server就會使用oozie server的啟動者的帳號去潤行這個任務, 如果oozie server的啟動者是管理員, 那麼使用者A就會獲取了管理員許可權, 這是很危險的. 所以proxy的目的就是確保使用者A 的任務執行過程中, 它只有使用者A的許可權, 不能越級!

YARN

Capacity Scheduler

capacity scheduler可以詳見這篇文章: https://www.cnblogs.com/bugsbunny/p/6773016.html

YARN的配置檔案裡可以定使用者是否有向queue提交app的許可權

使用yarn命令提交任務時可以通過引數指定

-D mapreduce.job.queuename=<pool name>

Hive

hive.server2.enable.doAs=True

是否使用提交hive查詢的使用者作為執行任務的使用者, 否則使用啟動hive server的使用者來執行query

Ranger

Hortonworks企業版的Hadoop系統中通常用apache ranger來進行許可權管理, 有圖形介面. 使用ranger的話, 就可以把doAs=False了, 因為ranger可以自行控制權限, 不必再借助HDFS的許可權管理了,當然你仍然可以把doAs 設定為True, 但可能會帶來不必要的錯誤.

Sentry

Cloudera 發行版的hadoop使用sentry來控制權限. 現在Hive的配置中關閉DoAs, 開啟sentry作為許可權管理.

使用SQL 語句來管理role和許可權:

GRANT SELECT ON DATABASE `database` TO ROLE `role_name`;
CREATE ROLE `role_name`;
GRANT ROLE `role_name1`, `role_name2` TO GROUP `group1`, GROUP `group2`;

• When Sentry is enabled, you must use Beeline to execute Hive queries. Hive CLI is not supported with Sentry and must be disabled. See Disabling Hive CLI.

Hue

(Cloudera)使用Hue來執行Hive Query時, 建立的檔案在hdfs裡會屬於組 supergroup, 擁有者的名字和Hue的登入使用者名稱一致.