Hadoop 中的 Kerberos id 和 认证

Kerberos 没有提供先进 id 功能，如分组和角色。特别是，Kerberos 将 id 表示为一个简单的两部分字符串或表示服务时的三部分字符串，一个短名称和一个领域。

kerberos 主体映射到用户名

Kerberos 使用了一个两部分字符串（如alice@EXAMPLE.COM）或三部分字符串（如hdfs/namenode.example.com@EXAMPLE.COM）,包含名称、领域和一个可选的实例名或主机名(hostname)。Hadoop将kerberos主体名称映射为本地用户名。 映射策略定义在krb5.conf文件的auth_to_local参数中，或core-site.xml中的hadoop特定规则hadoop.security.auth_to_local参数中。

hadoop 用户到用户组映射

hadoop用参数hadoop.security.group.mapping去控制用户到用户组的映射。默认实现是通过原生调用或本地shell命令，并利用标准UNIX接口去查找用户到组的映射。如果集群中各个主机定义的用户组不同，会导致用户到组的映射不一致。对于hadoop，映射发生在NodeNode、JobTracker(对于MR1)和ResourceManager(对于YARN/MR2)。

Hadoop 用户供给

hadoop集群需要一个统一的用户数据库，并且将用户同步到集群中所有服务器的本地操作系统中。并且要控制这些用户在本地操作系统中权限。

认证

Table 5-4. Hadoop ecosystem authentication methods

Kerberos

Hadoop支持两种认证机制：simple和kerberos。simple模式下，hadoop服务器信任所有的客户端。simple模式仅适合POC或实验室环境。

HDFS、MapReduce、YARN、HBase、Oozie和ZooKeeper都支持Kerberos作为客户端的一个认证机制，但实现因服务和接口有所不同。

对于以RPC为基础的协议，Simple Authentication and Security Layer (SASL)框架被用于在协议底层添加认证。理论上，所有SASL机制都应支持，实际上，仅支持GSSAPI(需要Kerberos V5)和DISGEST-MD5。

Oozie没有RPC协议，只提供REST接口。Oozie使用 Simpleand Protected GSSAPI Negotiation Mechanism (SPNEGO),一个通过HTTP进行Kerberos认证的协议。HDFS、MapReduce、YARN、Oozie和Hue的web接口，以及HDFS (both WebHDFS and HttpFS)和HBase的REST接口也支持SPNEGO。对于SASL和SPNEGO，

Alice使用kerberos通过HDFS NameNode认证的步骤：

1. Alice向位于kdc.example.com的TGS请求一个服务票据，请求的HDFS服务id是hdfs/namenode.example.com@EXAMPLE.COM，随请求附上她的TGT。
2. TGS验证TGT，然后为Alice提供一个服务票据(service ticket)，服务票据用主体hdfs/namenode.example.com@EXAMPLE.COM的key(密码)加密。
3. Alice发送服务票据到NameNode(通过SASL)，NameNode可以用hdfs/namenode.example.com@EXAMPLE.COM的key(也就是它自己的)解密和验证这个票据。

用户名和密码认证

Zookeeper支持通过用户名和密码的认证。用户名和密码认证由摘要认证供应商实现，供应商会生成用户名和密码的SHA-1摘要。

模拟(Impersonation)

Hadoop生态系统中有许多服务代表最终用户执行操作。为了确保安全，这些服务必须对客户端进行认证，以确保客户端可以模拟那些用户。 Oozie、Hive (in HiveServer2)和Hue都支持模拟最终用户访问HDFS、MapReduce、YARN或HBase。

模拟有时被称为代理(proxying)。可以执行模拟的用户(可以代理其他用户的用户)被称为代理人(proxy)。启用模拟的配置参数有三个，可以任意组合这三个参数：

hadoop.proxyuser.<proxy>.hosts               (指定模拟可以从哪台机器上发起)
hadoop.proxyuser.<proxy>.groups              (指定可以被模拟的用户所在的用户组)
hadoop.proxyuser.<proxy>.users               (指定可以被模拟的用户有哪几个)

其中<proxy>是执行模拟的用户的用户名，一般是超级用户，如hue、knox。值是逗号隔开的主机列表/用户组/用户列表，或*表示全部主机/用户组/用户。

如果你想要Hue和Oozie具有代理功能，但你想限制Oozie只能代理oozie-users用户组的用户，那么你最好使用类似下面的配置：

 <!-- 允许超级用户hue从节点hue.example.com上模拟所有用户组的最终用户 -->
 <property>
   <name>hadoop.proxyuser.hue.hosts</name>
   <value>hue.example.com</value>
 </property>
 <property>
   <name>hadoop.proxyuser.hue.groups</name>
   <value>*</value>
 </property>
<!-- 允许超级用户oozie从节点oozie01.example.com和oozie02.example.com上模拟用户组oozie-users中的最终用户 -->
 <property>
   <name>hadoop.proxyuser.oozie.hosts</name>
   <value>oozie01.example.com,oozie02.example.com</value>
 </property>
 <property>
   <name>hadoop.proxyuser.oozie.groups</name>
   <value>oozie-users</value>
 </property>

如果群集以安全模式运行，超级用户必须具有Kerberos凭据才能模拟另一个用户。

配置

当位置好kerberos认证后，所有用户和守护进程必须提供有效的凭据才能访问RPC接口。 这意味着你必须为集群中的每一个服务器/守护进程对创建一个kerberos服务凭据。回顾一下服务主体名称(SPN)的概念，它有三部分组成：一个服务名，一个主机名，和一个领域。在hadoop中，每个作为特定服务组成部分的守护进程使用这个服务名称(对于HDFS是hdfs，对于MapReduce是mapred，对于YARN是yarn)。另外，如果你想为各种web接口启用kerberos认证，那么你还需要为HTTP服务名称提供主体。

假设有一个hadoop集群的主机和服务如下表：

Table 5-5. Service layout

第一步是在 kerberos KDC 上创建所有需要的 SPN，然后为每个服务器上的每个守护进程到处一个keytab文件。需要的SPN列表如下：

Table 5-6. Required Kerberos principals

keytab文件的建议存放目录是$HADOOP_CONF_DIR目录(一般是/etc/hadoop/conf)。

当创建好需要的SPN，并将keytab文件分发好，需要配置Hadoop使用Kerberos认证。首先，设置core-site.xml文件的hadoop.security.authentication参数：

<property>
 <name>hadoop.security.authentication</name>
 <value>kerberos</value>
 </property>

以HDFS的配置文件是hdfs-site.xml。NameNode服务的配置如下：

<property>
 <name>dfs.block.access.token.enable</name>
 <value>true</value>
 </property>
 <property>
 <name>dfs.namenode.keytab.file</name>
 <value>hdfs.keytab</value>
 </property>
 <property>
 <name>dfs.namenode.kerberos.principal</name>
 <value>hdfs/_HOST@EXAMPLE.COM</value>
 </property>
 <property>
 <name>dfs.namenode.kerberos.internal.spnego.principal</name>
 <value>HTTP/_HOST@EXAMPLE.COM</value>
 </property>

上例中的_HOST是通配符，实际执行时会被替换为具体的主机名。