共计 3188 个字符，预计需要花费 8 分钟才能阅读完成。
默认安装好的 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
