手机版
你好,游客 登录 注册
背景:
阅读新闻

在Cloudera CDH 5.4.8上启用Kerberos (Ubuntu 14.04 LTS环境)

[日期:2017-11-08] 来源:Linux社区  作者:f1321368 [字体: ]

默认安装好的Cloudera CDH是没有启用security的。在非security的CDH环境中,至少会存在以下安全隐患:
1. 任何可以登录到RegionServer节点上的用户,都可以运行”hbase shell”名命令进入到hbase的shell,并且可以完全控制所有的table。
2. 通过HUE创建的用户,如果被授予了读写数据库的权限,那么他就可以完全控制所有的table。
3. 更严重的隐患,只需要知道任何一个ZooKeeper的IP地址,那么就可以在集群以外的位置运行通过HBase API实现的代码来完全控制HBase。

需要解决以上隐患,我们必须在CDH中启用security。CDH使用Kerberos作为Authentication和Authorization的工具。本篇文章主要介绍如何在CDH上启用Kerberos,以及启用Kerberos后出现的各种问题和解决方法。

一.启用Kerberos

1.安装Kerberos服务端

首先需要找一台主机安装Kerberos服务端。建议可以在运行Cloudera Manager的主机上安装。运行以下命令:

sudo apt-get install krb5-kdc
sudo apt-get install krb5-admin-server

安装过程中需要指定域名,Kerberos服务器,Kerberos管理服务器等。
域名可以填实际的域名:
这里写图片描述

Kerberos服务器可以填Cloudera Manager的完全主机名:
这里写图片描述

Kerberos管理服务器可以填Cloudera Manager的完全主机名:
这里写图片描述

2.配置Kerberos服务端

先创建新的数据库,执行以下命令,注意一定要记住设置的密码:

sudo krb5_newrealm

然后执行kadmin local进入管理界面,再添加管理员principal,Cloudera Manager将使用该管理员用户来创建其他相关的principal。参考以下命令:

#kadmin local
addprinc cloudera-scm/admin

修改ACL文件,使该principal具有管理员权限。修改/etc/krb5kdc/kadm5.acl文件,内容如下:

# This file Is the access control list for krb5 administration.
# When this file is edited run /etc/init.d/krb5-admin-server restart to activate
# One common way to set up Kerberos administration is to allow any principal 
# ending in /admin  is given full administrative rights.
# To enable this, uncomment the following line:
*/admin *
cloudera-scm/admin@BIGDATA.NET  *

3.安装Kerberos客户端

在CDH的所有节点上安装Kerberos客户端,运行以下命令:

sudo apt-get install krb5-user

然后测试Kerberos是否配置正确。在节点上运行“kinit”命令没有报错,然后运行”klist”能够看到票据即可。如下:
这里写图片描述

4.在集群上启用Kerberos

在Cloudera Manager界面点击“管理”下面的”Kerberos”(5.5.0版本以后为Security),再点“启用Kerberos”,然后根据提示完成即可。
这里写图片描述
后面的步骤没有截图,按照页面的提示完成。下面的截图是启用Kerberos之后,Kerberos的配置。注意红色框框部分的配置信息。
这里写图片描述

二.问题解决

启用Kerberos后,原来运行正常的集群会出现各种因为Security导致的问题。下面把碰到的问题和解决的方法做一个简单的描述。

1.启用Kerberos后,ZeeKeeper服务无法启动

问题分析:节点无法连接到KDC服务器,无法获取票据,导致所有服务都无法启动。这个貌似是CDH的一个BUG。CDH通过TCP协议连接KDC服务器,但是由KDC托管的krb5.conf文件默认设置成UDP协议。
解决方法:修改所有节点的/etc/krb5.conf文件,把udp_preference_limit的值修改为0,然后再重启集群即可。
这里写图片描述

2.通过HUE界面创建的Workflow在提交时直接失败,并且没有Job日志

问题分析:通过查看JobHistory的日志发现,该问题是在尝试创建Job日志时,没有权限写/yarn/nm/usercache/

3.通过HUE界面无法查看HBase的table

问题分析:配置问题。
解决方法:将Hbase的hbase.regionserver.thrift.http和hbase.thrift.support.proxyuser配置都设置为true,然后重启HBase即可。如下图:
这里写图片描述
或参考以下网址:http://gethue.com/hbase-browsing-with-doas-impersonation-and-kerberos/

4.在Hbase Shell中,没有权限运行任何命令

问题分析:配置问题。
解决方法:在Hbase的hbase.superuser中加入超级用户,然后重启HBase,再使用超级用户在Hbase Shell中运行grant命令进行授权。
这里写图片描述

5.包含Sqoop的Workflow在提交后,状态为PREP,之后报错

问题分析:这个问题困扰的时间最长,貌似是HUE3.7的BUG,将CDH升级到5.5.0,HUE3.9后问题得到解决。在HUE3.7的Workflow编辑界面,未提供job-xml的配置选项,导致Job无法完成。
解决方法:将HUE升级到3.9版本。然后再Sqoop步骤的配置中,将”作业XML”选项填入位于HDFS上的hbase-site.xml文件。
这里写图片描述
也可参考以下网址:http://ingest.tips/2015/02/12/sqoop-hbase-oozie/

6.Sqoop任务失败,日志提示“Hbase jars are not present in classpath, cannot import to hbase”

这里写图片描述
问题分析:其实我已经把以下文件(hbase-client.jar, hbase-protocol.jar, htrace-core.jar, hbase-server.jar, hbase-Hadoop-compat.jar, high-scale-lib-1.1.1.jar等,源文件位于/opt/cloudera/parcels/CDH-5.5.0-1.cdh5.5.0.p0.8/lib/hive/lib下)都上传到HDFS下面的/user/oozie/share/lib/lib_xxxxxxxx/sqoop目录下了,本来是不该出现这个提示的。不晓得是不是又是一个BUG,还是因为我把集群升级到5.5.0了。
解决方法:把HUE和Sqoop 2服务从CDH集群中删除,再重新添加这两个服务,并重启集群,问题就解决了。

7.Sqoop任务失败,日志提示没有权限在Hbase中执行”CREATE”

这里写图片描述
问题分析:相同的Sqoop命令在节点主机上执行没有任何问题。从日志分析,Job以oozie的身份来写Hbase,而不是当前的HUE用户。不晓得这个是不是BUG。
解决方法:暂时未找到解决办法。Workaround:在Hbase Shell中执行以下命令,授予oozie读写Hbase的权限。

grant 'oozie', 'RWC'

将来可能还会发现更多问题。到时候再列出来。

本文永久更新链接地址http://www.linuxidc.com/Linux/2017-11/148412.htm

linux
相关资讯       kerberos  CDH  Cloudera CDH 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款