Step by Step 实现基于 Cloudera 5.8.2 的企业级安全大数据平台 - Kerberos的整合

之前非常担心的一件事就是如果有人拿到了hdfs超级管理员帐号，直接把数据rm -rf怎么办？有了Kerberos，就可以轻松防止这样的事情发生。Kerberos 协议实现了比“质询－响应”模式协议更高的安全性：第一，在身份验证过程中，所有的数据都使用不同的密码进行加密，避免了相关验证信息的泄漏；第二，客户端和服务器会相互验证对方的身份，避免了 中间人攻击 ；第三，客户端和服务器间的时间差被严格限制，避免了 回放攻击 。与 WINDOWS 系统中的 用户安全令牌 类似， Kerberos 服务通过“ 加密的票据（防止篡改） ”验证用户身份和提供用户访问权限；Kerberos 服务可以通过使用 会话密钥 确保在会话中数据的机密性和完整性。

Kerberos相关术语

Kerberos认证过程

Kerberos 的认证过程如下图所示。我们可以简单的理解为，User 或者 Service 会用 Principal 到 AS 去认证(KRB_AS_REQ)，AS 会返回一个用 Principal Key 加密的 TGT(KRB_AS_REP)，这时候只有 AS 和这个 Principal 的使用者可以识别该 TGT。在拿到加密的 TGT 之后，User 或者 Service 会使用 Principal 的 Key 来解密 TGT，并使用解密后的 TGT 去 TGS 获取 Service Ticket(KRB_TGS_REQ, KRB_TGS_REP)。在 Kerberos 认证的集群中，只有拿着这个 Service Ticket 才可以访问真正的 Server 从而实现自己的业务逻辑(KRB_AP_REQ, KRB_AP_REP)。一般我们将 TGT 的存放文件，称为 Kerberos Confidential 文件，默认的存放目录为/tmp，文件名则由 krb5cc 和用户的 id 组成，例如“/tmp/krb5cc_0”为root的 confidential 文件。

图示：Kerberos 认证过程

Cloudera平台集成Kerberos

Cloudera提供了非常简便的Kerberos集成方式，基本做到了自动化部署。

系统：CentOS 7.2

操作用户：admin

角色分布如下：

• KDC已经安装好并且正在运行
• 将KDC配置为允许renewable tickets with non-zerolifetime，我们在之前修改kdc.conf文件的时候已经添加了max_life和max_renewable_life这个2个属性，前者表示服务端允许的Service ticket最大生命周期，后者表示服务端允许的Service ticket更新周期。这2个属性必须分别大于等于客户端对应的配置ticket_lifetime和renew_lifetime。我们假设，不这样进行配置：ticket_lifetime = 8d, max_life = 7d, renew_lifetime = 25h, max_renew_life = 24h，那么可能造成的结果就是当service持有的票据超过24小时没有去更新，在第24.5小时的时候去进行更新，请求会遭到拒绝，报错：Ticket expired while renewing credentials，永远无法进行正常更新。对于Cloudera来说，因为更新机制被透明(Cloudera有renew进程会去定期更新)，即使我们手动使用``modprinc -maxrenewlife 1week krbtgt/DOMAIN.COM@DOMAIN.COM` 进行更新，也无济于事。
• 在Cloudera Manager Server上安装openldap-clients；
• 为Cloudera Manager创建了超级管理员principal，使其能够有权限在KDC中创建其他的principals；

再次确认完毕后进入如下步骤：

1. 进入 Cloudera Manager Admin Console 界面并且点击 cluster 右边的按钮选择Enable Kerberos；
2. 点击 Continue，进入下一页进行配置，要注意的是：这里的 Kerberos Encryption Types 必须跟KDC实际支持的加密类型匹配（即kdc.conf中的值），这里使用了默认的aes256-cts，注意，这里的 Kerberos Encryption Types 必须和/etc/krb5.conf中的default_tgs_enctypes、default_tkt_enctypes和permitted_enctypes三个选项的值对应起来，不然会出现集群服务无法认证通过的情况！
3. 点击 Continue，进入下一页，这一页中不勾选 Manage krb5.conf through Cloudera Manager ，否则会修改掉之前配置的acl，造成 enable kerberos 失败；
4. 点击 Continue，进入下一页，输入 Cloudera Manager Principal 的管理员账号和密码，注意输入账号的时候要使用@前要使用全称，本文使用的是cdh-master/admin@DOMAIN.COM；
5. 点击 Continue，进入下一页，导入 KDC Account Manager Credentials；
6. 点击 Continue，进入下一页，Restart Cluster 并且Eenable Kerberos；

之后 Cloudera Manager 会自动重启集群服务，启动之后会提示 Kerberos 已启用。在 Cloudera Manager 上启用 Kerberos 的过程中，会自动做以下的事情：

• 集群中有多少个节点，每个账户就会生成对应个数的 principal ;
• 为每个对应的 principal 创建 keytab；
• 部署 keytab 文件到指定的节点中；
• 在每个服务的配置文件中加入有关 Kerberos 的配置；

其中包括Zookeeper服务所需要的 jaas.conf 和 keytab 文件都会自动设定并读取，如果用户仍然手动修改了Zookeeper的服务，要确保这两个文件的路径和内容正确性。

• keytab 是包含 principals 和加密 principal key 的文件 ；
• keytab 文件对于每个 host 是唯一的，因为 key 中包含 hostname ；
• keytab 文件用于保存纯文本密码，实现到 kerberos上 验证一个主机的 principal ；

启用之后访问集群的所有资源都需要使用相应的账号来访问，否则会无法通过 Kerberos 的 authenticatin。 除此之外，对于特定的服务需要做额外配置，本文只介绍HDFS、YARN、HBase，其余服务请参照官方文档自行进行配置。 对于HDFS，需要开启Web Concole 的认证，以防未认证用户访问资源界面，请在HDFS服务的Configuration中进行配置： Enable Kerberos Authentication for HTTP Web-Consoles = true 对于YARN，需要开启Web Concole 的认证，以防未认证用户访问资源界面，请在YARN服务的Configuration中进行配置： Enable Kerberos Authentication for HTTP Web-Consoles = true 对于HBase需要开启 Thrift 认证： HBase Thrift Authentication = auth 完成修改后，通过Cloudera Manager对HDFS服务进行重启。 相关测试 完成部署后，需要进行相关测试，以验证Kerberos是否被正常开启，本文纯属抛砖引玉，对部分服务进行了验证。 基本功能测试 在192.168.1.1 KDC 服务端上新建principal： kadmin.local -q "addprinc <user_name>/DOMAIN.COM@DOMAIN.COM" 在客户端192.168.1.2上新建principal： kinit cdh-master/admin@DOMAIN.COM kadmin -q "addprinc <user_name>/DOMAIN.COM@DOMAIN.COM" 销毁ticket缓存： kdestroy 查看当前ticket缓存，这时应会报错No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)： klist -f 重新获取ticket： kinit <user_name>/DOMAIN.COM@DOMAIN.COM 查看当前ticket缓存，应该不会报错： klist -f Hive功能测试 CLI测试，首先进行principal初始化 kadmin -q "addprinc hive/test@DOMAIN.COM" kinit hive/test@DOMAIN.COM 在没有配置 kerberos 之前，想要通过 hive 用户运行 hive 命令需要执行sudo，现在配置了 kerberos 之后，不再需要 sudo 了，hive 会通过 ticket 中的用户去执行该命令： CREATE DATABASE test; USE test; CREATE TABLE t(id int); DROP TABLE t; DROP DATABASE test; Beeline/JDBC测试： beeline --verbose=true beeline > !connect jdbc:hive2://${HIVE_SERVER2_HOSTNAME}:10000/default;principal=hive/${HIVE_SERVER2_HOSTNAME}@DOMAIN.COM; HUE Sqoop Action测试，唯一需要注意的是，在提交 Action的时候需要选择credential方式，hive shell action请选择 hcat，hive server2 action 请选择hive2，否则无法通过认证。 HBase on HUE功能测试 这里我们需要测试的是在HUE界面中进行HBase查询。在使用HBase时，如果登录HUE时使用的是admin身份，admin会伪装成hue用户发起命令，所以需要使用hbase的超级用户hbase去给hue赋权，才可以使其具备权限，才可以在HUE界面进行HBase查询： kdestroy kinit cdh-master/admin kadmin > addprinc hbase/test@DOMAIN.COM kinit hbase/test@DOMAIN.COM hbase shell hbase shell > grant 'hue','RWXCA' Sqoop on HUE功能测试 在Hue界面进行操作，添加sqoop1作业： sqoop list-databases --connect jdbc:mysql://${MYSQL_SERVER_FQDN}:3306 --username ${MYSQL_USERNAME} --password ${MYSQL_PASSWD} sqoop import --connect jdbc:mysql://${MYSQL_SERVER_FQDN}:3306/cm --username ${MYSQL_USERNAME} --password ${MYSQL_PASSWD} --table HOSTS --target-dir /user/admin/tgt -m 1 --delete-target-dir 如何在HUE中提交作业，这里不进行复述。 遇到的问题 Q: kerberos ticket renewer 服务报：Ticket expired while renewing credentials。 A: 这是因为TGT的ticketkrbtgt/DOMAIN.COM@DOMAIN.COM的renewlife被设置成了0，这一点可以通过kadmin => getprinc krbtgt/DOMAIN.COM@DOMAIN.COM看出来。将krbtgt/DOMAIN.COM@DOMAIN.COM的renewlife修改为 7d 即可，方法: modprinc -maxrenewlife 1week krbtgt/DOMAIN.COM@DOMAIN.COM Q: 提交Spark作业时报错：Delegation Token can be issued only with kerberos or web authentication。 A: 提交spark作业的时候需要指定 spark master = yarn mode = cluster Q: Beeline报错，Failed to find any Kerberos tgt。 A: 因为sudo权限下生成的credetial不能用于非sudo权限下的beeline，也就是说不要在申请ticket的时候使用sudo，在执行beeline的时候使用非sudo。