[译文]hadoop的授权和身份验证

授权和身份验证在hadoop中是一个较易混淆的主题,首先也是最重要的事情是辨别在授权和身份验证之间这种细微而极其重要的差别,首先我们来定义这些术语: Authentication 身份验证的目的是确认当前所声称为某种身份的用户,确实是所声称的用户。 Authorization 授权的功能是定义资源的访问权限。 简单来说,身份验证是提供我是谁的一种方式,授权是决定我能做什么的方式。

身份验证

如果Hadoop的所有配置都是默认的话,Hadoop不会验证用户。这是一个重要的体现,因为它可以在企业的数据中心造成严重影响。让我们来看看这个例子. 假设用户Joe可以访问一个Hadoop集群。这个集群并没有任何Hadoop安全特性((Hadoop security features) 启用,这意味着不会尝试去验证用户的标识。这个集权的超级用户是hdfs,Joe没有用户hdfs的密码。然而Joe刚好有一个客户端机器,有一些配置可以让 Joe访问Hadoop集群,Joy心情不顺,执行以下命令:

sudo useradd hdfs

sudo -u hdfs hadoop fs -rmr /

集群执行以上工作,然后回头告诉你“Ok, hdfs, I deleted everything!”。 那么发生了什么?在一个非安全的集群,NameNode 和 JobTracker不会需要任何身份验证。如果你发起一个请求,声称你是hdfs或者mapred, NN/JT都会说“ok, I believe that,”允许你做任何hdfs 或mapred可以做的事。 Hadoop有能力要求身份验证,以Kerberos的形式。Kerberos是一种身份验证的协议,用 “tickets” 允许节点标识自身,如果你想深入了解Kerberos,我强烈推荐看看这Wikipedia page. Hadoop可使用Kerberos协议确保当有人发出请求,他们真的是他们所说的。这种机制被用于在整个群集。在一个安全的Hadoop配置,所有的Hadoop守护进程使用Kerberos进行相互认证,这意味着,当两个守护进程相互交谈,他们每个确保其他守护进程是谁。此外,这允许的NameNode和JobTracker确保任何HDFS或MR请求被用适当的授权级别执行。

授权

授权跟验证是非常不同的。授权告诉我们任何给定的用户在Hadoop集群内可以做或不可以做的事,用户成功验证之后。在HDFS中,这主要是通过文件权限来制约。 HDFS文件权限与BSD文件的权限是非常相似的。如果你曾经使用ls-l在一个目录中,你可能已经看到这样的记录:

drwxr-xr-x 2 natty hadoop 4096 2012-03-01 11:18 foo

-rw-r–r– 1 natty hadoop 87 2012-02-13 12:48 bar

在最左侧,有一个字母字符串。第一个字母确定文件是否是一个目录或不是,然后有三组,每组三个字母。这些集表示所有者,组和其他用户的权限,而“RWX”读,写和执行权限,接下来“natty hadoop”部分表示该文件是由natty拥有,属于hadoop组。顺便说一句,一个规定的意图是-HDFS的语义是“尽可能类似Unix”。其结果是, certain HDFS operations follow BSD semantics, and others are closer to Unix semantics. 这里真正的问题是:什么是Hadoop的用户或组?答案是:他们是字符的字符串。仅此而已。 Hadoop的会很高兴地让你运行下面的命令

hadoop fs -chown fake_user:fake_group /test-dir

这样做的副作用是如果用户和组确实不存在,没有人可以访问这个文件除非是超级用户,默认的包括hdfs,mapred和其他hadoop超级组的成员。 在MapReduce的上下文中,用户和组用于确定谁允许提交或修改job.在MapReduce中job是由调度奇来控制队列提交。管理员可以定义允许谁通过 MapReduce ACLs将job提交到特定的队列。这些ACLs也可以基于 job-by-job来定义。类似于HDFS的权限,如果制定的用户或组不存在,则队列将不可用,除非由超级用户(总是可以提交或修改job) 接下来要问的问题是:NameNode和JobTracker如何找出用户属于哪个用户组的? 当用户运行Hadoop的命令时,NameNode会或的JobTracker获取有关用户正在运行该命令的一些信息。最重要的是,它知道该用户的用户名。后台程序,然后使用该用户名来确定用户所属的组。这是通过使用一个可插入的接口,它有接受用户名,并将其映射到该用户所属的组的能力。在默认安装中,用户-用户组的映射实现 forks off 子进程执行id -Gn [username]。提供如下列表:

natty@vorpal:~/cloudera $ id -Gn natty
natty adm lpadmin netdev admin sambashare hadoop hdfs mapred

Hadoop守护进程,然后使用组列表,以及用户名来确定用户是否具有所要求的适当的权限来访问该文件。也有一些包与Hadoop的其他实现,其中包括一个允许系统配置为get user-group mappings from an LDAP or Active Directory systems(从LDAP或Active Directory系统获取用户组映射)。如果有必要设立权限的组驻留在LDAP系统,这是非常有用的,但不是在unix上的集群主机。 一个需要注意的是,该组基团的的NameNode和JobTracker的都知道的可能比用户所属的客户端机器上的组群的不同。所有授权完成在NameNode会/ JobTracker的水平,所以对的DataNodes和的TaskTracker的用户和组不会影响授权,但如果启用了Kerberos身份验证,他们可能是必要的。此外,这是非常重要的的NameNode和JobTracker的两个明白的相同基团的任何给定的用户,或者在执行作业时,有可能是不确定的结果。如果对于用户所属的组有任何疑问,Hadoop的dfsgroups和Hadoop的mrgroups可以用来找出用户所属的组,分别依据 NameNode 和 JobTracker

全部放在一起

Hadoop的一个适当的,安全的安全协议可能需要将授权和认证结合起来。管理员应该看他们的安全需求,并确定哪些解决方案最适合他们,他们能有多大的风险承担对数据的处理上。此外,如果你要启用的Hadoop的Kerberos功能,我强烈建议去看看Cloudera Manager,它有助于使Kerberos的配置和设置非常容易。 原文:http://blog.cloudera.com/blog/2012/03/authorization-and-authentication-in-hadoop/