hadoop的simple认证

目前Hadoop的稳定版本为1.2.1，我们的实验就在hadoop-1.2.1上进行

Hadoop 版本:1.2.1

OS 版本: Centos6.4

环境配置

简单介绍一下hadoop安全需要哪些授权

先来看一下hdfs，当一个用户需要读写hadoop集群上的一个文件时，他通常先跟namenode联系，这就需要namenode的认证（org.apache.hadoop.hdfs.protocol.ClientProtocol定义了需要授权的接口），当namenode成功的认证client用户时，会返回给用户存储文件的datanode，client需要读写datanode上的数据时，同样也需要datanode的认证（org.apache.hadoop.hdfs.protocol.ClientDatanodeProtocol定义了需要授权的接口）。datanode和namenode之间也需要联系，datanode需要定时向namenode发送heartbeat和数据块的信息（org.apache.hadoop.hdfs.server.protocol.DatanodeProtocol定义了需要授权的接口）。Datanode之间也要发生数据交换，比如负载均衡，数据失效（org.apache.hadoop.hdfs.server.protocol.InterDatanodeProtocol定义了需要授权的接口）。Hadoop通常还需要一个secondnamenode来备份数据，因为secondnamenode定期向namenode发送数据请求，这中间也需要namenode的认证（org.apache.hadoop.hdfs.server.protocol.NamenodeProtocol定义了需要授权的接口）。还有两个不常用的授权org.apache.hadoop.security.authorize.RefreshAuthorizationPolicyProtocol和org.apache.hadoop.security.RefreshUserMappingsProtocol，这两个授权时检查是否有刷新授权和用户的权限。

我们再来看一下mapred框架需要哪些授权

当一个client写好map和reduce以及其他相关的程序后，他首先向jobtracker提交job，这就需要得到jobtracker的授权（org.apache.hadoop.mapred.JobSubmissionProtocol定义了需要授权的接口）。提交的job经过jobtracker调度后，会合理的分配到tasktracker节点上，hadoop采用的是tasktracker向jobtracker发送heartbeat或其他信息的返回值来得到task的信息，而不是jobttracker将task推送给tasktracker，也就是说tasktracker需要jobtracker的认证（org.apache.hadoop.mapred.InterTrackerProtocol定义了需要授权的接口）。还有一个必要重要的授权，tasktracker在得到task后，不是直接在自己的进程里执行，而是启动一个叫做Child的子进程，tasktracker和这些Child子进程(通常最多只有两个map和两个reduce)需要交换数据。尽管linux存在很多种进程共享数据的方式，Child和tasktracker还是通过网络的方式来的，这个交换过程主要都是由Child发起的。所以这些Child也需要得到tasktracer的认证（org.apache.hadoop.mapred.TaskUmbilicalProtocol定义了需要授权的接口）。跟hdfs一样，mapredu中也有两个不常用的授权org.apache.hadoop.security.authorize.RefreshAuthorizationPolicyProtocol和org.apache.hadoop.security.RefreshUserMappingsProtocol，这两个授权时检查是否有刷新授权和用户的权限。

这些授权都在org.apache.hadoop.hdfs.HDFSPolicyProvider和org.apache.hadoop.mapred.MapReducePolicyProvider中定义，有兴趣的可能看看。

简单方式配置

conf/core-site.xml加上

<property>

<name>hadoop.security.authorization</name>

<value>true</value>

</property>

<property>

<name>hadoop.security.authentication</name>

<value>simple</value>

</property>

下面做一些简单测试，来验证一下配置

测试代码1

Configuration conf =
new Configuration();

conf.set("fs.default.name", "hdfs://hadoop1:9000");

FileSystem hdfs =
FileSystem.get(conf);

Path path =
new Path("/user/hadoop/input");

FileStatus[] files =
hdfs.listStatus(path);

for(int i=0; i< files.length; i++ ){

System.out.println(files[i].getPath());

}

控制台打出的结果

Exception in thread "main"
org.apache.hadoop.ipc.RemoteException: User test is not authorized for protocol
interface org.apache.hadoop.hdfs.protocol.ClientProtocol, expected client
Kerberos principal is null

at
org.apache.hadoop.ipc.Client.call(Client.java:1113)

at
org.apache.hadoop.ipc.RPC$Invoker.invoke(RPC.java:229)

at
com.sun.proxy.$Proxy1.getProtocolVersion(Unknown Source)

at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at
java.lang.reflect.Method.invoke(Method.java:601)

at
org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:85)

at
org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:62)

at
com.sun.proxy.$Proxy1.getProtocolVersion(Unknown Source)

at
org.apache.hadoop.ipc.RPC.checkVersion(RPC.java:422)

at
org.apache.hadoop.hdfs.DFSClient.createNamenode(DFSClient.java:183)

at
org.apache.hadoop.hdfs.DFSClient.<init>(DFSClient.java:281)

at
org.apache.hadoop.hdfs.DFSClient.<init>(DFSClient.java:245)

at
org.apache.hadoop.hdfs.DistributedFileSystem.initialize(DistributedFileSystem.java:100)

at
org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:1446)

at
org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:67)

at
org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:1464)

at
org.apache.hadoop.fs.FileSystem.get(FileSystem.java:263)

at
org.apache.hadoop.fs.FileSystem.get(FileSystem.java:124)

at test.TestHdfs.main(TestHdfs.java:18)

从上面的结果可以看出，client机器上的test用户没有权限访问hdfs系统。当我们将代码稍作改变，见测试代码2：

测试代码2

Configuration conf =
new Configuration();

conf.set("fs.default.name", "hdfs://hadoop1:9000");

//FileSystem hdfs = FileSystem.get(conf);

FileSystem hdfs =
FileSystem.get(new URI("hdfs://hadoop1:9000"), conf,
"hadoop");

Path path =
new Path("/user/hadoop/input");

FileStatus[] files =
hdfs.listStatus(path);

for(int i=0; i< files.length; i++ ){

System.out.println(files[i].getPath());

控制台打出的结果

hdfs://hadoop1:9000/user/hadoop/input/Balancer.java

hdfs://hadoop1:9000/user/hadoop/input/BalancerBandwidthCommand.java

hdfs://hadoop1:9000/user/hadoop/input/BlockAlreadyExistsException.java

hdfs://hadoop1:9000/user/hadoop/input/BlockCommand.java

很显然，使用hadoop用户来访问hdfs就没有任何问题。换一句话说，一旦客户端知道hadoop集群的用户，就可以执行hdfs的操作。这将会存在很大的安全隐患。至少应该有一个登录系统来提供一个认证功能。

目前常用的认证的方式有如下几种：

1. 用户名/密码认证。这是一种常用方式，当用户数量比较多时，可以采用sql/ldap方式。这种方式通常性能较能。


2. 机器地址过滤。
   这种方式通常有两种方式实行，黑名单列表：机器不能访问，白名单列表：机器能够访问。这种方式尽管配置简单，但是部署比较麻烦，通常表现在：一次修改到处部署。Hadoop实现了此种方式：dfs.hosts，dfs.hosts.exclude。但默认不使用

Kerboros方式，hadoop1后面都实现了这种方式，而且推荐使用这种方式。