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
Service | Protocol | Methods |
---|---|---|
HDFS | RPC | Kerberos, delegation token |
HDFS | Web UI | SPNEGO (Kerberos), pluggable |
HDFS | REST (WebHDFS) | SPNEGO (Kerberos), delegation token |
HDFS | REST (HttpFS) | SPNEGO (Kerberos), delegation token |
MapReduce | RPC | Kerberos, delegation token |
MapReduce | Web UI | SPNEGO (Kerberos), pluggable |
YARN | RPC | Kerberos, delegation token |
YARN | Web UI | SPNEGO (Kerberos), pluggable |
Hive Server 2 | Thrift | Kerberos, LDAP (username/password) |
Hive Metastore | Thrift | Kerberos, LDAP (username/password) |
Impala | Thrift | Kerberos, LDAP (username/password) |
HBase | RPC | Kerberos, delegation token |
HBase | Thrift Proxy | None |
HBase | REST Proxy | SPNEGO (Kerberos) |
Accumulo | RPC | Username/password, pluggable |
Accumulo | Thrift Proxy | Username/password, pluggable |
Solr | HTTP | Based on HTTP container |
Oozie | REST | SPNEGO (Kerberos, delegation token) |
Hue | Web UI | Username/password (database, PAM, LDAP), SAML, OAuth, SPNEGO (Kerberos), remote user (HTTP proxy) |
ZooKeeper | RPC | Digest (username/password), IP, SASL (Kerberos), pluggable |
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认证的步骤:
- Alice向位于kdc.example.com的TGS请求一个服务票据,请求的HDFS服务id是hdfs/namenode.example.com@EXAMPLE.COM,随请求附上她的TGT。
- TGS验证TGT,然后为Alice提供一个服务票据(service ticket),服务票据用主体hdfs/namenode.example.com@EXAMPLE.COM的key(密码)加密。
- 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
Hostname | Daemon |
---|---|
nn1.example.com | NameNode |
JournalNode | |
nn2.example.com | NameNode |
JournalNode | |
snn.example.com | SecondaryNameNode |
JournalNode | |
rm.example.com | ResourceManager |
jt.example.com | JobTracker |
JobHistoryServer | |
dn1.example.com | DataNode |
TaskTracker | |
NodeManager | |
dn2.example.com | DataNode |
TaskTracker | |
NodeManager | |
dn3.example.com | DataNode |
TaskTracker | |
NodeManager |
第一步是在 kerberos KDC 上创建所有需要的 SPN,然后为每个服务器上的每个守护进程到处一个keytab文件。需要的SPN列表如下:
Table 5-6. Required Kerberos principals
Hostname | Daemon | Keytab file | SPN |
---|---|---|---|
nn1.example.com | NameNode/JournalNode | hdfs.keytab | hdfs/nn1.example.com@EXAMPLE.COM |
HTTP/nn1.example.com@EXAMPLE.COM | |||
nn2.example.com | NameNode/JournalNode | hdfs.keytab | hdfs/nn2.example.com@EXAMPLE.COM |
HTTP/nn2.example.com@EXAMPLE.COM | |||
snn.example.com | SecondaryNameNode/JournalNode | hdfs.keytab | hdfs/snn.example.com@EXAMPLE.COM |
HTTP/snn.example.com@EXAMPLE.COM | |||
rm.example.com | ResourceManager | yarn.keytab | yarn/rm.example.com@EXAMPLE.COM |
jt.example.com | JobTracker | mapred.keytab | mapred/jt.example.com@EXAMPLE.COM |
HTTP/jt.example.com@EXAMPLE.COM | |||
JobHistoryServer | mapred.keytab | mapred/jt.example.com@EXAMPLE.COM | |
dn1.example.com | DataNode | hdfs.keytab | hdfs/dn1.example.com@EXAMPLE.COM |
HTTP/dn1.example.com@EXAMPLE.COM | |||
TaskTracker | mapred.keytab | mapred/dn1.example.com@EXAMPLE.COM | |
HTTP/dn1.example.com@EXAMPLE.COM | |||
NodeManager | yarn.keytab | yarn/dn1.example.com@EXAMPLE.COM | |
HTTP/dn1.example.com@EXAMPLE.COM | |||
dn2.example.com | DataNode | hdfs.keytab | hdfs/dn2.example.com@EXAMPLE.COM |
HTTP/dn2.example.com@EXAMPLE.COM | |||
TaskTracker | mapred.keytab | mapred/dn2.example.com@EXAMPLE.COM | |
HTTP/dn2.example.com@EXAMPLE.COM | |||
NodeManager | yarn.keytab | yarn/dn2.example.com@EXAMPLE.COM | |
HTTP/dn2.example.com@EXAMPLE.COM | |||
dn3.example.com | DataNode | hdfs.keytab | hdfs/dn3.example.com@EXAMPLE.COM |
HTTP/dn3.example.com@EXAMPLE.COM | |||
TaskTracker | mapred.keytab | mapred/dn3.example.com@EXAMPLE.COM | |
HTTP/dn3.example.com@EXAMPLE.COM | |||
NodeManager | yarn.keytab | yarn/dn3.example.com@EXAMPLE.COM | |
HTTP/dn3.example.com@EXAMPLE.COM |
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
是通配符,实际执行时会被替换为具体的主机名。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论