HDFS Yarn Oozie Hive 权限管理

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:

 

    hadoop.proxyuser.oozie.hosts
    *



    hadoop.proxyuser.oozie.groups
    *

让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=

 

 

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的登录用户名一致.