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源码，添加自己的验证体系了。