1.简单模式
这种模式,配置简单,使用简单。
core-site.xml添加
<property> <name>hadoop.security.authorization</name> <value>true</value> </property> <property> <name>hadoop.security.authentication</name> <value>simple</value> </property>
hadoop.security.authentication可以不用配,默认就是simple的。
hadoop-policy.xml,是设置各种服务对应的可登陆的用户和组,*自然是所有的,看里面的注释就可以了,或者直接看官方文档http://hadoop.apache.org/docs/r2.4.1/hadoop-project-dist/hadoop-common/ServiceLevelAuth.html,里面有详细的介绍和使用方式。
可登录的用户在列表里面,实际运行时,还要看用户对各种资源的rwx权限,这个权限要用“hadoop fs”相关的命令进行设置了,和linux系统下设置文件权限是一样的。
问题在于这种登录,有个用户名就可以,安全性不高啊,果然是简单模式。实际应用时,就自己用用还是可以的,搭配下防火墙应该问题不大。但是,如果要对外提供服务啥的,这问题还是不小的,伪造个用户名连接上服务,只要一行代码设置环境变量就伪造好了。。。
2.kerberos认证
官方文档先挂上http://hadoop.apache.org/docs/stable2/hadoop-project-dist/hadoop-common/SecureMode.html
core-site.xml
<property> <name>hadoop.security.authorization</name> <value>true</value> </property> <property> <name>hadoop.security.authentication</name> <value>kerberos</value> </property>
接着就是安装kerberos,再就是一堆的配置啥的,然后,看到篇文章介绍支付宝hadoop集群使用kerberos的情况,里面所说,对于用户权限的修改,机器的减容扩容,会造成证书要重新生成,再分发证书,重启hadoop,而且还要考虑kerberos的宕机导致整个集群无法服务的风险,还有支付宝的那个例子,运维都难,还是不用了。。。
3.看来是要修改hadoop源码,添加自己的验证体系了。