CDH 的Kerberos认证配置

2019独角兽企业重金招聘Python工程师标准>>>

最近因为项目需要，需要对用户权限做限制，最终选择了kerberos+sentry+hue模式来管理用户，但是这个kerberos实在搞得我头大的不行，在网上找各种资料，怎么配置都不行，后来索性静下心来研究官方文档，在经历３天的痛苦折腾之后，终于实现了成功启动kerberos，为了各位能少走弯路我把我的经验写出来，供有缘人借鉴并少走弯路。

其实自己走了一遍后，真的是很简单，只是我自己当初想的太复杂，没有搞清楚cdh的原理，cdh自己都配置好的，我自己只需保证整个集群KDC组是通的即可，其他都不需要自己手动操作，现在终于明白了网上那些博客都是自己手动安装kerberos才需要大量的配置密钥和创建规则，言归正传。

我的环境很简单１０个节点，我的配置是１个节点做cdh的server＋CDH的server是单独存放监听的东西，上面hadoop的什么服务都不放，２个节点做namenode 其余７个节点是namenode

配置kdc集群的先解决条件

server 主机配置如下

1.主配hosts置文件如下（所有机器）

cat /etc/hosts

192.168.237.230  masternode01

192.168.237.231  masternode02

192.168.237.232  slavenode02

192.168.237.233  slavenode03

192.168.237.234  slavenode04

192.168.237.235 slavenode05

192.168.237.236  slavenode06

192.168.237.237  slavenode07

192.168.237.238  slavenode08

192.168.237.239  slavenode09

 

２．server 安装kerberos相关软件

install the kerberos components

yum install -y krb5-server　openldap-clients　krb5-workstation

[root@masternode01 jce]#yum install -y krb5-server　 openldap-clients krb5-workstation

３．修改/etc/krb5.conf配置文件

[root@masternode01 jce]#sed -i.orig 's/HADOOP.COM/HADOOP.COM/g' /etc/krb5.conf

[root@masternode01 jce]#sed -i.m1 's/kerberos.example.com/masternode01/g' /etc/krb5.conf

[root@masternode01 jce]#sed -i.m2 's/example.com/hadoop.com/g' /etc/krb5.conf

sed -i.m3 '/supported_enctypes/a default_principal_flags = +renewable, +forwardable' /var/kerberos/krb5kdc/kdc.conf

sed -i.m4 's/^default_principal_flags/  default_principal_flags/' /var/kerberos/krb5kdc/kdc.conf

 

[root@masternode01 ~]# cat /var/kerberos/krb5kdc/kdc.conf

[kdcdefaults]

 kdc_ports = 88

 kdc_tcp_ports = 88

 

[realms]

 HADOOP.COM = {

  #master_key_type = aes256-cts

  acl_file = /var/kerberos/krb5kdc/kadm5.acl

  dict_file = /usr/share/dict/words

  max_renewable_life = 7d

  max_life = 1d

  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab

  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal

  default_principal_flags = +renewable, +forwardable

 }

root@masternode01 ~]# cat /etc/krb5.conf

[libdefaults]

default_realm = HADOOP.COM

dns_lookup_kdc = false

dns_lookup_realm = false

ticket_lifetime = 86400

renew_lifetime = 604800

forwardable = true

default_tgs_enctypes = rc4-hmac aes128-cts des3-hmac-sha1

default_tkt_enctypes = rc4-hmac aes128-cts des3-hmac-sha1

permitted_enctypes = rc4-hmac aes128-cts des3-hmac-sha1

udp_preference_limit = 1

kdc_timeout = 3000

[realms]

HADOOP.COM = {

kdc = masternode01

admin_server = masternode01

} 

[domain_realm]

 .hadoop.com = HADOOP.COM

 hadoop.com = HADOOP.COM

关于AES-256加密

对于使用 centos5. 6及以上的系统，默认使用 AES-256 来加密的。这就需要集群中的所有节点上安装 Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy File。

下载的文件是一个 zip 包，解开后，将里面的两个文件放到下面的目录中：$JAVA_HOME/jre/lib/security

mkdir ~/jce

cd ~/jce

unzip UnlimitedJCEPolicyJDK7.zip

 

cp /usr/java/jdk1.7.0_80/jre/lib/security/local_policy.jar local_policy.jar.orig

cp /usr/java/jdk1.7.0_80/jre/lib/security/US_export_policy.jar  US_export_policy.jar.orig

 

cp /root/jce/UnlimitedJCEPolicy/local_policy.jar /usr/java/jdk1.7.0_80/jre/lib/security/local_policy.jar

cp /root/jce/UnlimitedJCEPolicy/US_export_policy.jar /usr/java/jdk1.7.0_80/jre/lib/security/US_export_policy.jar

 

５．生成master服务器上的kdc database

kdb5_util create -s -r HADOOP.COM

# 保存路径为/var/kerberos/krb5kdc 如果需要重建数据库，将该目录下的principal相关的文件删除即可

在此过程中，我们会输入database的管理密码。这里设置的密码一定要记住，如果忘记了，就无法管理Kerberos server。

当Kerberos database创建好后，可以看到目录 /var/kerberos/krb5kdc 下生成了几个文件：

[root@masternode01 ~]# ls /var/kerberos/krb5kdc

hdfs.keytab  kadm5.acl  kdc.conf.m1  kdc.conf.m3  kdc.conf.orig  principal.kadm5       principal.ok

HTTP.keytab  kdc.conf   kdc.conf.m2  kdc.conf.m4  principal      principal.kadm5.lock

若要从新初始化数据库则需要删除　

rm -rf /var/kerberos/krb5kdc/principal*

之后在重新初始化数据即可　kdb5_util create -s -r HADOOP.COM　

在maste服务器上创建admin用户

在maste KDC上执行：

kadmin.local -q "addprinc admin/admin"

在KDC上我们需要编辑acl文件来设置权限，该acl文件的默认路径是 /var/kerberos/krb5kdc/kadm5.acl（也可以在文件kdc.conf中修改）。Kerberos的kadmind daemon会使用该文件来管理对Kerberos database的访问权限。对于那些可能会对pincipal产生影响的操作，acl文件也能控制哪些principal能操作哪些其他pricipals。

 

我们现在为administrator设置权限：将文件/var/kerberos/krb5kdc/kadm5.acl的内容编辑为

[root@masternode01 jce]# cat /var/kerberos/krb5kdc/kadm5.acl

*/[email protected]*

7．在master KDC启动Kerberos daemons

手动启动：

[root@masternode01 jce]# service krb5kdc start

[root@masternode01 jce]# service kadmin start

设置开机自动启动：

[root@masternode01 jce]# chkconfig krb5kdc on

[root@masternode01 jce]# chkconfig kadmin on

8.配置客户端服务器

Configuring Kerberos Clients

 Installing Kerberos Client(CentOS7可以省略此步骤)

在另外几台主机安装kerberos客户端。

yum install krb5-workstation krb5-libs krb5-auth-dialog

用kinit 命令，测试admin账户是否生成成功

kinit  admin/[email protected]

配置krb5.conf

配置这些主机上的/etc/krb5.conf，这个文件的内容与KDC中的文件保持一致即可。

[root@masternode01 jce]# for i in {31,32,33,34,35,36,37,38,39} ;do scp /etc/krb5.conf [email protected]$i:/etc/;done

9.验证KDC是否生效

[root@masternode01 ~]# kadmin

Authenticating as principal admin/[email protected] with password.

Password for admin/[email protected]: 

kadmin:

其他客户端验证方法如下：

[root@slavenode04 ~]# kinit admin/admin

Password for admin/[email protected]: 

You have new mail in /var/spool/mail/root

不保持就说明kdc已经通

 

之后既可以去cdh界面开启kerberos即可，所有的配置cdh自己就写入到kdc的配置文件了，包括给用户创建密钥，自己只需要创建一个cdh可一导入的用户密钥即可，我现在用的是之前创建的admin用户导入，有人喜欢用此用户cloudera-scm管理cdh，那在开启kerberos时要写这个用户的密码

，其余任何用户都不需要添加，不要手动创建任何一个keytab，

 

[root@masternode01 ~]# kadmin

Authenticating as principal admin/[email protected] with password.

Password for admin/[email protected]: 

kadmin:

kadmin:  addprinc cloudera-scm/admin

WARNING: no policy specified for [email protected]; defaulting to no policy

Enter password for principal "[email protected]": 输入密码一定要记住

Re-enter password for principal "[email protected]": 

Principal "[email protected]" created.

 

 

 

 

之后开启sentry服务在cdh集群里，只需要在界面添加即可。

 

整个kerberos开启成功。

由于最近一段时间的研究，发现要是手动安装kerberos也很简单，只需要把所有的机器上的所在的用户都创建相应的key即可。不需要额外添加没必要的key，希望对你们有帮助。

CDH 的Kerberos认证配置

博客分类：   Hadoop

 

http://xubo8118.blog.163.com/blog/static/1855523322013918103857226/

关于：

hadoop的安全机制 

hadoop kerberos的安全机制

 

参考Cloudera官方文档：Configuring Hadoop Security in CDH3

 

一、部署无kerberos认证的Hadoop环境

参考另一篇笔记：hadoop集群部署

或者按照Cloudera的官方文档：CDH3 Installation Guide.

 

二、环境说明

1、主机名

之前部署hadoop集群时，没有使用节点的hostname，而是在hosts文件里添加了ip要域名的解析，部署后的hadoop没有问题，但是在为集群添加kerberos认证时因为这一点，遇到很多的问题。所以，建议还是使用节点的hostname来做解析。

 

集群中包含一个NameNode/JobTracker，两个DataNode/TaskTracker。

 

hosts文件

1. 172.18.6.152 nn.hadoop.local
2. 172.18.6.143 dn143.hadoop.local
3. 172.18.6.145 dn145.hadoop.local

注意：hosts文件中不要包含127.0.0.1的解析。

 

2、hadoop安装部署相关

hadoop 和kerberos的部署需要hadoop-sbin和hadoop-native。

如果使用的是rpm部署的hadoop，需要安装上面的两个rpm包。

我的集群使用的是tar包部署的，所以默认是包含这两部分文件的，可以检查一下：

hadoop-sbin对应的文件是：

/usr/local/hadoop/sbin/Linux-amd64-64

文件夹中包含两个文件：jsvc、task-controller

 

hadoop-native对应的目录是：

/usr/local/hadoop/lib/native

 

3、AES-256加密

我的系统使用的是centos6.2和centos5.7，对于使用centos5.6及以上的系统，默认使用AES-256来加密的。这就需要集群中的所有节点和hadoop user machine上安装 Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy File

打开上面的链接，在页面的下方，下载jdk对应的文件，jdk1.6.0_22下载下面的文件：

注：如果后面出现login failed的错误，应先检查是否是从官方网站下载的JCE。

下载的文件是一个zip包，解开后，将里面的两个文件放到下面的目录中：

/usr/java/jdk1.6.0_22/jre/lib/security

注：也可以不使用AED-256加密，方法见官方文档对应的部分。

 

三、部署KDC

1、安装kdc server

只需要在kdc中安装

yum install krb5-server.x86_64  krb5-devel.x86_64

 

2、配置文件

kdc服务器涉及到三个配置文件：

/etc/krb5.conf、

/var/kerberos/krb5kdc/kdc.conf、

/var/kerberos/krb5kdc/kadm5.acl

 

 

hadoop集群中其他服务器涉及到的kerberos配置文件：/etc/krb5.conf。

将kdc中的/etc/krb5.conf拷贝到集群中其他服务器即可。

集群如果开启selinux了，拷贝后可能需要执行restorecon -R -v /etc/krb5.conf

 

/etc/krb5.conf

1. [logging]
2. default = FILE:/var/log/krb5libs.log
3. kdc = FILE:/var/log/krb5kdc.log
4. admin_server = FILE:/var/log/kadmind.log
5. [libdefaults]
6. default_realm = for_hadoop
7. dns_lookup_realm = false
8. dns_lookup_kdc = false
9. ticket_lifetime = 24h
10. renew_lifetime = 2d
11. forwardable = true
12. renewable = true
13. [realms]
14. for_hadoop = {
15. kdc = 172.18.6.152:88
16. admin_server = 172.18.6.152:749
17. }
18. [domain_realm]
19. [kdc]
20. profile=/var/kerberos/krb5kdc/kdc.conf

/var/kerberos/krb5kdc/kdc.conf

1. [kdcdefaults]
2. kdc_ports = 88
3. kdc_tcp_ports = 88
4. [realms]
5. for_hadoop = {
6. master_key_type = aes256-cts
7. max_life = 25h
8. max_renewable_life = 4w
9. acl_file = /var/kerberos/krb5kdc/kadm5.acl
10. dict_file = /usr/share/dict/words
11. admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
12. supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md
13. 5:normal des-cbc-crc:normal
14. }

/var/kerberos/krb5kdc/kadm5.acl

 

1. */admin@for_hadoop *

3、创建数据库

 

1. #kdb5_util create -r for_hadoop -s

 

该命令会在/var/kerberos/krb5kdc/目录下创建principal数据库。

 

4、关于kerberos的管理

可以使用kadmin.local或kadmin,至于使用哪个，取决于账户和访问权限：

kadmin.local（on the KDC machine）or kadmin （from any machine）

如果有访问kdc服务器的root权限，但是没有kerberos admin账户，使用kadmin.local

如果没有访问kdc服务器的root权限，但是用kerberos admin账户，使用kadmin

 

5、创建远程管理的管理员

1. #kadmin.local
2. addprinc root/admin@for_hadoop

密码不能为空，且需妥善保存。

 

6、创建测试用户

1. #kadmin.local
2. addprinc test

 

7、常用kerberos管理命令

1. #kadmin.local
2. 列出所有用户 listprincs
3. 查看某个用户属性，如 getprinc hdfs/nn.hadoop.local@for_hadoop
4. 注意，是getprinc，没有's'
5. 添加用户 addprinc
6. 更多，查看帮助

8、添加kerberos自启动及重启服务

1. chkconfig --level 35 krb5kdc on
2. chkconfig --level 35 kadmin on
3. service krb5kdc restart
4. service kadmin restart

9、测试

使用之前创建的test用户

1. # kinit test
2. Password for test@for_hadoop:
3. #

输入密码后，没有报错即可。

1. # klist -e
2. Ticket cache: FILE:/tmp/krb5cc_0
3. Default principal: test@for_hadoop
4. Valid starting Expires Service principal
5. 06/14/12 15:42:33 06/15/12 15:42:33 krbtgt/for_hadoop@for_hadoop
6. renew until 06/21/12 15:42:33, Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC
7. Kerberos 4 ticket cache: /tmp/tkt0
8. klist: You have no tickets cached

可以看到，已经以test@for_hadoop登陆成功。

 

四、为hadoop创建认证规则（Principals）和keytab

1、一些概念

Kerberos principal用于在kerberos加密系统中标记一个唯一的身份。

kerberos为kerberos principal分配tickets使其可以访问由kerberos加密的hadoop服务。

对于hadoop，principals的格式为username/[email protected].

 

keytab是包含principals和加密principal key的文件。

keytab文件对于每个host是唯一的，因为key中包含hostname。keytab文件用于不需要人工交互和保存纯文本密码，实现到kerberos上验证一个主机上的principal。

因为服务器上可以访问keytab文件即可以以principal的身份通过kerberos的认证，所以，keytab文件应该被妥善保存，应该只有少数的用户可以访问。

 

按照Cloudrea的文档，我们也使用两个用户hdfs和mapred，之前已经在linux上创建了相应的用户。

 

2、为集群中每个服务器节点添加三个principals，分别是hdfs、mapred和host。

1. 创建hdfs principal
2. kadmin: addprinc -randkey hdfs/nn.hadoop.local@for_hadoop
3. kadmin: addprinc -randkey hdfs/dn143.hadoop.local@for_hadoop
4. kadmin: addprinc -randkey hdfs/dn145.hadoop.local@for_hadoop
5. 创建mapred principal
6. kadmin: addprinc -randkey mapred/nn.hadoop.local@for_hadoop
7. kadmin: addprinc -randkey mapred/dn143.hadoop.local@for_hadoop
8. kadmin: addprinc -randkey mapred/dn145.hadoop.local@for_hadoop
9. 创建host principal
10. kadmin: addprinc -randkey host/nn.hadoop.local@for_hadoop
11. kadmin: addprinc -randkey host/dn143.hadoop.local@for_hadoop
12. kadmin: addprinc -randkey host/dn145.hadoop.local@for_hadoop
13. 创建完成后，查看：
14. kadmin: listprincs

3、创建keytab文件

创建包含hdfs principal和host principal的hdfs keytab

1. kadmin: xst -norandkey -k hdfs.keytab hdfs/fully.qualified.domain.name host/fully.qualified.domain.name

创建包含mapred principal和host principal的mapred keytab

1. kadmin: xst -norandkey -k mapred.keytab mapred/fully.qualified.domain.name host/fully.qualified.domain.name

 

 

注：上面的方法使用了xst的norandkey参数，有些kerberos不支持该参数，我在Centos6.2上即不支持该参数。

当不支持该参数时有这样的提示：Principal -norandkey does not exist.

需要使用下面的方法来生成keytab文件。

 

生成独立key

1. # cd /var/kerberos/krb5kdc
2. #kadmin
3. kadmin: xst -k hdfs-unmerged.keytab hdfs/nn.hadoop.local@for_hadoop
4. kadmin: xst -k hdfs-unmerged.keytab hdfs/dn143.hadoop.local@for_hadoop
5. kadmin: xst -k hdfs-unmerged.keytab hdfs/dn145.hadoop.local@for_hadoop
6.  
7. kadmin: xst -k mapred-unmerged.keytab mapred/nn.hadoop.local@for_hadoop
8. kadmin: xst -k mapred-unmerged.keytab mapred/dn143.hadoop.local@for_hadoop
9. kadmin: xst -k mapred-unmerged.keytab mapred/dn145.hadoop.local@for_hadoop

1. kadmin: xst -k host.keytab host/nn.hadoop.local@for_hadoop
2. kadmin: xst -k host.keytab host/dn143.hadoop.local@for_hadoop
3. kadmin: xst -k host.keytab host/dn145.hadoop.local@for_hadoop

合并key

使用ktutil 合并前面创建的keytab

1. # cd /var/kerberos/krb5kdc
2. #ktutil
3. ktutil: rkt hdfs-unmerged.keytab
4. ktutil: rkt host.keytab
5. ktutil: wkt hdfs.keytab
6. ktutil: clear
7. ktutil: rkt mapred-unmerged.keytab
8. ktutil: rkt host.keytab
9. ktutil: wkt mapred.keytab

 

这个过程创建了两个文件，hdfs.keytab和mapred.keytab，分别包含hdfs和host的principals，mapred和host的principals。

 

使用klist显示keytab文件列表，一个正确的hdfs keytab文件看起来类似于：

 

1. #cd /var/kerberos/krb5kdc
2. #klist -e -k -t hdfs.keytab
3. Keytab name: WRFILE:hdfs.keytab
4. slot KVNO Principal
5. ---- ---- ---------------------------------------------------------------------
6. 1 7 host/[email protected] (DES cbc mode with CRC-32)
7. 2 7 host/[email protected] (Triple DES cbc mode with HMAC/sha1)
8. 3 7 hdfs/[email protected] (DES cbc mode with CRC-32)
9. 4 7 hdfs/[email protected] (Triple DES cbc mode with HMAC/sha1)

验证是否正确合并了key，使用合并后的keytab，分别使用hdfs和host principals来获取证书。

 

1. # kinit -k -t hdfs.keytab hdfs/[email protected]
2. # kinit -k -t hdfs.keytab host/[email protected]

如果出现错误：

 "kinit: Key table entry not found while getting initial credentials",

则上面的合并有问题，重新执行前面的操作。

 

4、部署kerberos keytab文件

在集群中所有节点，执行下面的操作来部署hdfs.keytab和mapred.keytab文件

 

拷贝hdfs.keytab和mapred.keytab文件到hadoop可以访问的目录。

1. scp hdfs.keytab mapred.keytab host:/usr/local/hadoop/conf

确保hdfs.keytab对hdfs用户可读

确报mapred.keytab对mapred用户可读

后面经常会遇到使用keytab login失败的问题，首先需要检查的就是文件的权限。

 

五、停止hadoop集群

 

六、Enable Hadoop Security

在集群中所有节点的core-site.xml文件中添加下面的配置

2.   hadoop.security.authentication
3.   kerberos 
5.  
7.   hadoop.security.authorization
8.   true

七、Configure Secure HDFS1、在集群中所有节点的hdfs-site.xml文件中添加下面的配置 

3.   dfs.block.access.token.enable
4.   true
6.  
9.   dfs.https.address
10.   :50470
13.   dfs.https.port
14.   50470
17.   dfs.namenode.keytab.file
18.   /usr/local/hadoop/conf/hdfs.keytab 
21.   dfs.namenode.kerberos.principal
22.   hdfs/[email protected]
25.   dfs.namenode.kerberos.https.principal
26.   host/[email protected]
28.  
31.   dfs.secondary.https.address
32.   :50495
35.   dfs.secondary.https.port
36.   50495
39.   dfs.secondary.namenode.keytab.file
40.   /usr/local/hadoop/conf/hdfs.keytab 
43.   dfs.secondary.namenode.kerberos.principal
44.   hdfs/[email protected]
47.   dfs.secondary.namenode.kerberos.https.principal
48.   host/[email protected]
50.  
53.   dfs.datanode.data.dir.perm
54.   700
57.   dfs.datanode.address
58.   0.0.0.0:1004
61.   dfs.datanode.http.address
62.   0.0.0.0:1006
65.   dfs.datanode.keytab.file
66.   /usr/local/hadoop/conf/hdfs.keytab 
69.   dfs.datanode.kerberos.principal
70.   hdfs/[email protected]
73.   dfs.datanode.kerberos.https.principal
74.   host/[email protected]

2、启动namenode

1. # sudo -u hdfs /usr/local/hadoop/bin/hadoop namenode

启动后可以看到下面的信息

1. 10/10/25 17:01:46 INFO security.UserGroupInformation:
2. Login successful for user hdfs/[email protected] using keytab file /etc/hadoop/hdfs.keytab

1. 10/10/25 17:01:52 INFO security.UserGroupInformation: Login successful for user host/[email protected] using keytab file /etc/hadoop/hdfs.keytab
2. 10/10/25 17:01:52 INFO http.HttpServer: Added global filtersafety (class=org.apache.hadoop.http.HttpServer$QuotingInputFilter)
3. 10/10/25 17:01:57 INFO http.HttpServer: Adding Kerberos filter to getDelegationToken
4. 10/10/25 17:01:57 INFO http.HttpServer: Adding Kerberos filter to renewDelegationToken
5. 10/10/25 17:01:57 INFO http.HttpServer: Adding Kerberos filter to cancelDelegationToken
6. 10/10/25 17:01:57 INFO http.HttpServer: Adding Kerberos filter to fsck
7. 10/10/25 17:01:57 INFO http.HttpServer: Adding Kerberos filter to getimage

关于错误：

1. 12/06/13 13:24:43 WARN ipc.Server: Auth failed for 127.0.0.1:63202:null
2. 12/06/13 13:24:43 WARN ipc.Server: Auth failed for 127.0.0.1:63202:null
3. 12/06/13 13:24:43 INFO ipc.Server: IPC Server listener on 9000: readAndProcess threw exception javax.security.sasl.SaslException: GSS initiate failed [Caused by GS***ception: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)] from client 127.0.0.1. Count of bytes read: 0
4. javax.security.sasl.SaslException: GSS initiate failed [Caused by GS***ception: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)]

1. 12/06/13 13:23:21 WARN security.UserGroupInformation: Not attempting to re-login since the last re-login was attempted less than 600 seconds before.

这两个错误与前面提到的JCE jar包有关，确保已经下载并替换了相应的jar包。

 

如果出现Login failed，应首先使用kinit的方式登陆，如果可以登陆，检查是否使用了正确的JCE jar包。然后就是检查keytab的路径及权限。

 

另外，第二个错误，也有可能与SELINUX有关，在所有配置不变的情况下，关闭selinux可以解决问题。但是在/var/log/audit/audit.log里没有看到相关的错误。之后不知何故，开启selinux也不会造成上面的那个问题了。

 

3、验证namenode是否正确启动

两种方法：

（1）访问http://machine:50070

（2）

1. #hadoop fs -ls

注：如果在你的凭据缓存中没有有效的kerberos ticket，执行hadoop fs -ls将会失败。

可以使用klist来查看是否有有有效的ticket。

可以通过kinit来获取ticket.

kinit -k -t /usr/local/hadoop/conf/hdfs.ketab hdfs/nn.hadoop.local@for_hadoop

如果没有有效的ticket，将会出现下面的错误：

1. 11/01/04 12:08:12 WARN ipc.Client: Exception encountered while connecting to the server : javax.security.sasl.SaslException:
2. GSS initiate failed [Caused by GS***ception: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
3. Bad connection to FS. command aborted. exception: Call to nn-host/10.0.0.2:8020 failed on local exception: java.io.IOException:
4. javax.security.sasl.SaslException: GSS initiate failed [Caused by GS***ception: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]

注：如果使用的MIT kerberos 1.8.1或更高版本，ORACLE JDK6 UPDATE 26和更早的版本存在一个bug：

即使成功的使用kinit获取了ticket，java仍然无法读取kerberos 票据缓存。

解决的办法是在使用kinit获取ticket之后使用kinit -R 来renew ticket。这样，将重写票据缓存中的ticket为java可读的格式。

但是，在使用kinit -R 时遇到一个问题，就是无法renew ticket

 

1. kinit: Ticket expired while renewing credentials

在官方文档中也有描述：Java is unable to read the Kerberos credentials cache created by versions of MIT Kerberos 1.8.1 or higher.

关于是否以获取renew的ticket，取决于KDC的设置。

是否是可以获取renew的ticket，可以通过klist来查看：

如果不可以获取renw的ticket，”valid starting" and "renew until"的值是相同的时间。

我为了获取renw的ticket，做了以下的尝试：

<1>、在kdc.conf中添加默认flag

default_principal_flags = +forwardable,+renewable

但是实际没有起作用，因为查看资料，默认的principal_flags就包含了renewable，所以问题不是出在这里。

另外需要说明一点，default_principal_flags 只对这个flags生效以后创建的principal生效，之前创建的不生效，需要使用modprinc来使之前的principal生效。

 

<2>、在kdc.conf中添加：

1. max_renewable_life = 10d

重启kdc， 重新kinit -k -t .....，重新执行kinit -R可以正常renw了。

再次验证，修改为：

1. max_renewable_life = 0s

重启kdc，重新kinit -k -t ......，重新执行 kinit -R在此不能renew ticket了。

所以，是否可以获取renew的ticket是这样设置的：

默认是可以获取renew的ticket的，但是，可以renw的最长时间是0s，所以造成无法renew，解决的办法是在kdc.conf中增大该参数。

 

另外关于krb5.conf中的renew_lifetime = 7d参数，该参数设置该服务器上的使用kinit -R时renew的时间。

 

另外，也可以通过modprinc来修改max_renewable_life的值，使用modprinc修改的值比kdc.conf中的配置有更高的优先级，例如，使用modprinc设置了为7天，kdc.conf中设置了为10天，使用getprinc可以看出，实际生效的是7天。需要注意的是，即要修改krbtgt/for_hadoop@for_hadoop，也要修改类似于hdfs/dn145.hadoop.local@for_hadoop这样的prinicials，通过klist可以看出来：

 

1. # klist
2. Ticket cache: FILE:/tmp/krb5cc_0
3. Default principal: hdfs/dn145.hadoop.local@for_hadoop
4. Valid starting Expires Service principal
5. 06/14/12 17:15:05 06/15/12 17:15:05 krbtgt/for_hadoop@for_hadoop
6. renew until 06/21/12 17:15:04
7. Kerberos 4 ticket cache: /tmp/tkt0
8. klist: You have no tickets cached

如何使用modprinc来修改max_renewable_life

1. #kadmin.local
2. modprinc -maxrenewlife 7days krbtgt/for_hadoop@for_hadoop
3. getprinc krbtgt/for_hadoop@for_hadoop
4. Principal: krbtgt/for_hadoop@for_hadoop
5. Expiration date: [never]
6. Last password change: [never]
7. Password expiration date: [none]
8. Maximum ticket life: 1 day 00:00:00
9. Maximum renewable life: 7 days 00:00:00
10. Last modified: Thu Jun 14 11:25:15 CST 2012 (hdfs/admin@for_hadoop)
11. Last successful authentication: [never]
12. Last failed authentication: [never]
13. Failed password attempts: 0
14. Number of keys: 7
15. Key: vno 1, aes256-cts-hmac-sha1-96, no salt
16. Key: vno 1, aes128-cts-hmac-sha1-96, no salt
17. Key: vno 1, des3-cbc-sha1, no salt
18. Key: vno 1, arcfour-hmac, no salt
19. Key: vno 1, des-hmac-sha1, no salt
20. Key: vno 1, des-cbc-md5, no salt
21. Key: vno 1, des-cbc-crc, no salt

到这里，kinit -R的问题解决，可以成功的执行hadoop fs -ls了。

 

4、启动datanode

正确的启动方法应该是使用root账号

1. HADOOP_DATANODE_USER=hdfs sudo -E /usr/local/hadoop/bin/hadoop datanode

如果使用其他用户，直接执行hadoop datanode，则会报错：

1. 11/03/21 12:46:57 ERROR datanode.DataNode: java.lang.RuntimeException: Cannot start secure cluster without privileged resources. In a secure cluster, the DataNode must
2. be started from within jsvc. If using Cloudera packages, please install the hadoop-0.20-sbin package.
3. For development purposes ONLY you may override this check by setting dfs.datanode.require.secure.ports to false. *** THIS WILL OPEN A SECURITY HOLE AND MUST NOT BE
4. USED FOR A REAL CLUSTER ***.
5. at org.apache.hadoop.hdfs.server.datanode.DataNode.startDataNode(DataNode.java:306)
6. at org.apache.hadoop.hdfs.server.datanode.DataNode.(DataNode.java:280)
7. at org.apache.hadoop.hdfs.server.datanode.DataNode.makeInstance(DataNode.java:1533)
8. at org.apache.hadoop.hdfs.server.datanode.DataNode.instantiateDataNode(DataNode.java:1473)
9. at org.apache.hadoop.hdfs.server.datanode.DataNode.createDataNode(DataNode.java:1491)
10. at org.apache.hadoop.hdfs.server.datanode.DataNode.secureMain(DataNode.java:1616)
11. at org.apache.hadoop.hdfs.server.datanode.DataNode.main(DataNode.java:1626)

官方文档中提到了这个问题：

Cannot start secure cluster without privileged resources.

官方的解释是和jsvc有关，确实，与jsvc有关.

（1）、有可能没有安装hadoop-sbin。

 （2）、确保jsv对于HADOOP_DATANODE_USER=hdfs有可执行的权限。

（3）、通过查看hadoop这个启动脚本，可以看到这样的代码：

1. if [ "$EUID" = "0" ] ; then
2. if [ "$COMMAND" == "datanode" ] && [ -x "$_JSVC_PATH" ]; then
3. _HADOOP_RUN_MODE="jsvc"
4. elif [ -x /bin/su ]; then
5. _HADOOP_RUN_MODE="su"
6. else

检查执行hadoop命令的用户的EUID是否为0，即root，只有root用户才去执行jsvc相关的命令。

关于EUID：linux系统中每个进程都有2个ID，分别为用户ID（uid）和有效用户ID（euid），UID一般表示进程的创建者（属于哪个用户创建），而EUID表示进程对于文件和资源的访问权限（具备等同于哪个用户的权限）。一般情况下2个ID是相同的。

 

5、 Set the Sticky Bit on HDFS Directories.

可以针对hdfs上的目录设置sticky bit，用于防止除superuser，owner以外的用户删除文件夹中的文件。对一个文件设置sticky bit是无效的。

 

八、Start up the Secondary NameNode

跳过

 

九、Configure Secure MapReduce

在mapred-site.xml中添加

 

3.   mapreduce.jobtracker.kerberos.principal
4.   mapred/[email protected]
7.   mapreduce.jobtracker.kerberos.https.principal
8.   host/[email protected]
11.   mapreduce.jobtracker.keytab.file
12.   /usr/local/hadoop/conf/mapred.keytab 
14.  
17.   mapreduce.tasktracker.kerberos.principal
18.   mapred/[email protected]
21.   mapreduce.tasktracker.kerberos.https.principal
22.   host/[email protected]
25.   mapreduce.tasktracker.keytab.file
26.   /usr/local/hadoop/conf/mapred.keytab 
28.  
31.   mapred.task.tracker.task-controller
32.   org.apache.hadoop.mapred.LinuxTaskController
35.   mapreduce.tasktracker.group
36.   mapred

 

创建一个taskcontroller.cfg文件，路径为

/../../conf/taskcontroller.cfg

即/usr/local/hadoop/sbin/Linux-amd64-64/../../conf/taskcontroller.cfg

即conf目录，和site文件相同的目录

1. mapred.local.dir=/hadoop_data/tmp/mapred/local
2. hadoop.log.dir=/usr/local/hadoop/logs
3. mapreduce.tasktracker.group=hadoop
4. banned.users=hadoop,hdfs,bin
5. min.user.id=500

其中：

mapred.local.dir需要和mapred-site.xml中指定的相同，否则this error message 

hadoop.log.dir要和hadoop所使用的目录相同，可以在core-site.xml中指定，不同的话会报错：this error message

另外mapred.local.dir的属主为mapred用户:

1. chown -R mapred.mapred  /hadoop_data/tmp/mapred/local

Note
In the taskcontroller.cfg file, the default setting for the banned.users property is mapred, hdfs, and bin to prevent jobs from being submitted via those user accounts. The default setting for themin.user.id property is 1000 to prevent jobs from being submitted with a user ID less than 1000, which are conventionally Unix super users. Note that some operating systems such as CentOS 5 use a default value of 500 and above for user IDs, not 1000. If this is the case on your system, change the default setting for the min.user.id property to 500. If there are user accounts on your cluster that have a user ID less than the value specified for the min.user.id property, the TaskTracker returns an error code of 255.

 

修改task-controller文件的权限：

More Information about the hadoop-0.20-sbin Binary Programs.

 

1. chown root:mapred /usr/local/hadoop/sbin/Linux-amd64-64/task-controller
2. chmod 4754 /usr/local/hadoop/sbin/Linux-amd64-64/task-controller

 

启动JOBTRACKER

1. sudo -u mapred /usr/local/hadoop/bin/hadoop jobtracker

错误：

1. FATAL mapred.JobTracker: org.apache.hadoop.security.AccessControlException: The systemdir hdfs://nn.hadoop.local:9000/hadoop_data/tmp/mapred/system is not owned by mapred

修改hdfs上对应目录的属性

1. hadoop fs -chown -R mapred /hadoop_data/tmp/mapred

注意，是mapred而不是mapred.mapred，否则会变成 mapred.mapred supergroup          0 2012-06-08 11:41 /hadoop_data/tmp/mapred/system

 

重新启动JobTracker。

 

到这里JobTracker启动完成，最后一步，启动TaskTracker

修改taskcontroller.cfg文件属性，启动tasktracker时会检查（jobtracker不需要？待验证）

1. chown root.mapred taskcontroller.cfg
2. chmod 600 taskcontroller.cfg

同样的，也需要修改task-controler的属性

1. chown root:mapred  /usr/local/hadoop/sbin/Linux-amd64-64/task-controller
2. chmod 4754 /usr/local/hadoop/sbin/Linux-amd64-64/task-controller

启动

1. sudo -u mapred /usr/local/hadoop/bin/hadoop tasktracker

错误：

1. ERROR mapred.TaskTracker: Can not start task tracker because java.io.IOException: Login failure for mapred/srv143.madeforchina.co@for_hadoop from keytab /usr/local/hadoop/mapred.keytab

使用kinit可以登陆？确保key对于mapred用户可读。

 

另外，可以还需要修改log目录的权限

1. chown -R mapred.hadoop /usr/local/hadoop/logs/

到这里，hadoop + kerberos基本完后。

 

后面需要做的工作包括修改启动hadoop的脚本，部署kerberos slave服务器。

4. 为CDH 5集群添加Kerberos身份验证
4.1 安装sentry
　　1、点击“操作”，“添加服务”；
　　2、选择sentry，并“继续”；

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3、选择一组依赖关系

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4、确认新服务的主机分配

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5、配置存储数据库；

　　在mysql中创建对应用户和数据库：

1
2
3
mysql>create database sentry default character set utf8 collate utf8_general_ci;
mysql>grant all on sentry.* to 'admin'@'server35' identified by '111111';
mysql>flush privileges;
6、测试连接

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7、创建Sentry数据表，启动Sentry服务

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4.2 详细部署过程

4.2.1 安装Cloudera Manager和CDH
　　如果您尚未执行此操作，Cloudera 强烈建议您首先安装和配置 Cloudera Manager Server 和 Cloudera Manager Agent 以及 CDH 来设置一个功能完备的 CDH 群集，然后再开始执行以下步骤来实施 Hadoop 安全功能。
4.2.2 如果您使用的是 AES-256 加密，请安装 JCE 策略文件（推荐不使用AES-256加密）
　　如果您使用的是 CentOS 或 RHEL 5.5 或更高版本（默认情况下对票证使用 AES-256 加密），您必须在所有群集和 Hadoop 用户主机上安装 Java Cryptography Extension (JCE) 无限制强度权限策略文件。可通过两种方法执行此操作：
　　1、 在 Cloudera Manager Admin Console 中，导航到主机页面。向群集添加新主机向导和重新运行升级向导都使您能够选择让 Cloudera Manager 为您安装 JCE 策略文件。
　　2、 您可以按照 jce_policy-x.zip 文件中包含的 README.txt 文件中的 JCE 策略文件安装说明进行操作。
　　注意：您可以通过从 kdc.conf 或 krb5.conf 文件的 supported_enctypes 字段中删除 aes256-cts:normal 来将 Kerberos 配置为不使用 AES-256。请注意，在更改 kdc.conf 文件之后，您需要重启 KDC 和 kadmin 服务器，这些更改才会生效。您可能还需要重新创建或更改相关主体的密码，可能包括 Ticket Granting Ticket 主体（例如，krbtgt/[email protected]）。如果在执行所有这些步骤之后仍在使用 AES- 256，这是因为在创建 Kerberos 数据库时存在 aes256-cts:normal 设置。要解决此问题，请创建新的 Kerberos 数据库，然后重启 KDC 和 kadmin 服务器。
4.2.3 为 Cloudera Manager Server 获取或创建 Kerberos 主体
　　为了能在集群中创建和部署host principals和keytabs，Cloudera Manager Server必须有一个Kerberos principal来创建其他的账户。如果一个principal的名字的第二部分是admin（例如， username/[email protected] ），那么该principal就拥有administrative privileges。

　　在KDC server主机上，创建一个名为[cloudra-scm]的principal，并为其设置密码。执行命令：

1
2
3
4
5
[root@vmw201 ~]# kadmin.local
Authenticating as principal root/[email protected] with password.
Kadmin.local: addprinc -pw cloudera-scm-1234 cloudera-scm/[email protected]
WARNING: no policy specified for cloudera-scm/[email protected]; defaulting to no policy
Principal "cloudera-scm/[email protected]" created.
　　输入listprincs可以看到创建了一个名为cloudera-scm/[email protected]的principal：

4.2.4 导入KDC Account Manager凭据
　　1、在 Cloudera Manager Admin Console 中，选择管理 > 安全 > Kerberos凭据。

 

 

 

 

 

 

2、导航到凭据选项卡并单击导入 Kerberos Account Manager 凭据。

3、在导入 Kerberos Account Manager 凭据对话框中，针对可以在 KDC 中为 CDH 群集创建主体的用户输入用户名和密码。这是您在4.1.3中：为 Cloudera Manager Server 获取或创建 Kerberos 主体 中创建的用户/主体。Cloudera Manager 会将用户名和密码加密到 Keytab 中，并在需要时使用它来创建新的主体。

 

 

 

 

 

 

 

 

 

 

 

4.2.5 在cloudera Manager Admin Console中配置Kerberos默认领域

　　1、在 Cloudera Manager Admin Console 中，选择管理 > 设置。
　　2、单击Kerberos类别，然后在 Kerberos 安全领域字段中为群集输入您在 krb5.conf 文件中配置的 Kerberos 领域（例如 EXAMPLE.COM 或 HADOOP.EXAMPLE.COM）、KDC Server主机、Kerberos加密类型。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3、 单击保存更改。

4.2.6 停止所有服务
　　1、在主页上，单机集群名称右侧的 ，停止所有服务。
　　2、在主页上，单击 Cloudera Management Service 右侧的 ，选择停止。
4.2.7 启用 HDFS安全性
　　1、点击主页上的HDFS，选择配置
　　2、修改下面参数

1
2
3
4
5
6
hadoop.security.authentication ---> kerberos
hadoop.security.authorization ---> true
dfs.datanode.data.dir.perm ---> 700
dfs.datanode.address --->1004
dfs.datanode.http.address --->1006
Hadoop.security.group.mapping->org.apache.hadoop.security.ShellBasedUnixGroupsMapping
　　3、单击保存更改
4.2.8 启用HBASE安全性
　　1、点击主页上的HBASE，选择配置
　　2、修改下面参数

1
2
hbase.security.authentication ---> Kerberos
hbase.security.authorization ---> true
　　3、 单击保存
4.2.9 启用kafka安全性
　　1、单击主页上的kafka，选择配置。
　　2、修改下面参数

1
2
kerberos.auth.enable ---> true
security.inter.broker.protocol ---> SASL_PLAINTEXT
　　3、单击保存
4.2.10 启用zookeeper安全性
　　1、单击主页上的zookeeper，选择配置。
　　2、修改下面参数

1
enableSecurity ---> true
　　3、单击保存
4.2.11 Hive开启sentry服务以及开启Hive安全性
　　1、在“Sentry 服务”中选择“Sentry”
　　2、修改下面参数

1
Hive.warehouse.subdir.inherit.perms-->true
　　3、选择hive-site.xml 的 Hive 服务高级配置代码段（安全阀），增加如下配置：

1
2
3
4

sentry.hive.testing.mode
false

　　4、选择“范围”中的“HiveServer2”，修改如下配置：

1
hive.server2.enable.impersonation, hive.server2.enable.doAs-->false
　　5、选择hive-site.xml 的 HiveServer2 高级配置代码段（安全阀），添加如下配置

1
2
3
4

hive.security.authorization.task.factory
org.apache.sentry.binding.hive.SentryHiveAuthorizationTaskFactoryImpl

6、选择hive-site.xml 的 Hive Metastore Server 高级配置代码段（安全阀），添加如下参数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

hive.metastore.client.impl
org.apache.sentry.binding.metastore.SentryHiveMetaStoreClient
Sets custom Hive Metastore client which Sentry uses to filter out metadata.


hive.metastore.pre.event.listeners
org.apache.sentry.binding.metastore.MetastoreAuthzBinding
list of comma separated listeners for metastore events.


hive.metastore.event.listeners
org.apache.sentry.binding.metastore.SentryMetastorePostEventListener
list of comma separated listeners for metastore, post events.


hive.metastore.filter.hook
org.apache.sentry.binding.metastore.SentryMetaStoreFilterHook

4.2.12 配置yarn
在“允许的系统用户”参数“allowed.system.users”中添加hive用户

1
Yarn->配置->min.user.id修改为合适的值，当前为0
4.2.13 配置sentry
　　管理员组(sentry.service.admin.group)和允许的连接用户(sentry.service.allow.connect)中添加admin用户和组；

　　选择“服务范围”，修改管理员组，将默认“hive”、“impala”、“hue”删除，并增加“admin”。

　　在sentry-site.xml 的 Sentry 服务高级配置代码段（安全阀）中添加如下参数：

1
2
3
4
5
6
7
8
9
10
11
12

sentry.service.processor.factories
org.apache.sentry.provider.db.service.thrift.SentryPolicyStoreProcessorFactory,org.apache.sentry.hdfs.SentryHDFSServiceProcessorFactory


sentry.policy.store.plugins
org.apache.sentry.hdfs.SentryPlugin


sentry.hdfs.integration.path.prefixes
/user/hive/warehouse

4.2.14 等待“生成凭据”命令完成
　　在 Cloudera Manager 中为任何服务启用安全保护之后，将自动触发称为“生成凭据”的命令。您可以在显示正在运行的命令的屏幕右上角看到该命令的进度。请等待此命令完成（通过内含“0”的灰色框表示）。
4.2.15 使 Hue 能够使用 Cloudera Manager 与 Hadoop 安全一起工作
　　如果您使用的是 Hue 服务，那么您必须向 Hue 服务添加 Kerberos Ticket Renewer 的角色实例，以使 Hue 能够使用 Cloudera Manager 与安全的 Hadoop 群集一起正常工作。

　　Hue Kerberos Ticket Renewer 仅为主体 hue/@HADOOP.COM续订 Hue 服务的票证。然后，将使用该 Hue 主体为 Hue 内的应用程序（如 Job Browser、File Browser 等）模拟其他用户。其他服务（如 HDFS 和 MapReduce）不使用 Hue Kerberos Ticket Renewer。它们将在启动时获取票证，并使用这些票证获取各种访问权限的委派令牌。每个服务根据需要处理自己的票证续订。

1. 转到Hue服务。
2. 单击实例选项卡。
3. 单击添加角色实例按钮。
4. 为与Hue Server相同的主机分配Kerberos Ticket Renewer序角色实例。

5. 在向导完成后，状态将显示已完成，并且 Kerberos Ticket Renewer 角色实例已配置。Hue 服务现在将与安全的 Hadoop 群集一起工作。
4.2.16启动所有服务 
启动所有服务，在主页上，单击群集名称右侧的 并选择启动。
启动 Cloudera Management Service，在主页上，单击Cloudera Management Service右侧的 并选择启动。
4.2.17 部署客户端配置
在主页，单击群集名称右侧的 ,并选择部署客户端配置。
4.2.18 创建 HDFS 超级用户主体
要为用户创建主目录，您需要对超级用户帐户具有访问权限。在 HDFS 中，运行 NameNode 进程的用户帐户（默认情况下为 hdfds）是一个超级用户。在安装 CDH 的过程中，CDH 会自动在每个群集主机上创建 hdfs 超级用户帐户。当为 HDFS 服务启用 Kerberos 时，您无法通过 sudo -u hdfs 命令访问 hdfs 超级用户帐户。要在 Kerberos 处于启用状态时能够访问 hdfs 超级用户帐户，您必须创建一个 Kerberos 主体或 AD 用户，并且其第一个或唯一一个组成部分必须是 hdfs。或者，您也可以指定其成员属于超级用户的超级用户组。

在kadmin.local或kadmin shell 中，键入以下命令来创建名为hdfs的Kerberos主体：

1
kadmin: addprinc [email protected]
此命令会提示您为 hdfs 主体创建密码。请使用强密码，因为此主体对 HDFS 中的所有文件提供超级用户访问权限。
要作为 hdfs 超级用户运行命令，您必须为 hdfs 主体获取 Kerberos 凭据。要执行此操作，请运行以下命令并提供密码：

1
$ kinit [email protected]
指定超级用户组
要指定超级用户组而不使用默认 hdfs 帐户，请按照以下步骤进行操作：
1.导航到HDFS服务 > 配置选项卡。
2.在“搜索”字段中键入超级用户以显示超级用户组属性。
3.将默认supergroup的值更改为适合您的环境的组名称。
4.单击保存更改。
为使此更改生效，您必须重启群集。
4.2.19 为每个用户帐户获取或创建 Kerberos 主体
在您的群集上配置和启用 Kerberos 之后，您和其他所有 Hadoop 用户都必须具有 Kerberos 主体或 Keytab 才能获取被允许访问该群集和使用 Hadoop 服务的 Kerberos 凭据。在此过程的下一步中，您需要创建自己的 Kerberos 主体，以便验证 Kerberos 安全是否正在您的群集上工作。如果您和其他 Hadoop 用户已经有 Kerberos 主体或 Keytab，或者您的 Kerberos 管理员可以提供它们，那么您可以直接跳到下一步。

在 kadmin.local 或 kadmin shell 中，使用以下命令为您的帐户创建主体，请将 username 替换为用户名：

1
kadmin: addprinc [email protected]
4.2.20为每个用户准备群集
在您和其他用户可以访问群集之前，您必须执行一些任务来为每个用户准备主机。
1. 确保群集中的所有主机都有一个linux用户帐户并且该帐户的名称与用户的主体名称的第一个组成部分相同。例如，如果用户的主体名称是 [email protected]，则每个框中应存在linux帐户joe。
2. 为每个用户帐户在 HDFS 上的 /user 下创建一个子目录（例如 /user/joe）。将该目录的所有者和组更改为该用户。

1
2
$ hadoop fs -mkdir /user/joe
$ hadoop fs -chown joe /user/joe
4.2.21为 Hadoop 角色的 HTTP Web Console 启用身份验证(可选)
HDFS、MapReduce 和 YARN 角色的 Web Console 的访问身份验证可通过相应的服务的配置选项启用。要启用此身份验证，请执行以下操作：
1.从群集选项卡中，选择要为其启用身份验证的服务（HDFS、MapReduce 或 YARN）。
2.单击配置选项卡。
3.展开服务范围 > 安全，选中启用 HTTP Web Console 的身份验证属性，然后保存您所做的更改。
将触发一个命令来生成新的所需凭据。
3. 在命令完成后，请重启该服务的所有角色。
4.2.22 确认Kerberos在集群上正常工作
登录到某一个节点后，切换到hdfs用户，然后用kinit来获取credentials 
现在用’hadoop dfs -ls /’应该能正常输出结果
用kdestroy销毁credentials后，再使用hadoop dfs -ls /会发现报错
4.3 kafka使用SASL验证
kafka目前支持的机制有GSSAPI(Kerberos)和PLAIN ，在以上步骤中，Kafka brokers的SASL已配置，接下来配置Kafka客户端
4.3.1 生成jaas文件
客户端（生产者，消费者，connect，等等）用自己的principal认证集群（通常用相同名称作为运行客户端的用户）。因此，获取或根据需要创建这些principal。然后，为每个principal创建一个JAAS文件，KafkaClient描述了生产者和消费者客户端如何连接到broker。下面是一个客户端使用keytab的配置例子（建议长时间运行的进程）。在/etc/kafka/目录下创建kafka_client_jaas.conf文件

1
2
3
4
5
6
7
KafkaClient {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
storeKey=true
keyTab="/etc/kafka/conf/kafka_client.keytab"
principal="[email protected]";
};
创建[email protected]

1
2
kadmin:addprinc -randkey kafka-client-1
kadmin:xst -k /etc/kafka/conf/kafka_client.keytab kafka-client-1
在使用producer和consumer java接口时，要在代码main方法中，加入

1
System.setProperty(“java.security.auth.login.config”,”/etc/kafka/kafka_client_jaas.conf”);
保证程序可以读取到jaas文件。
在producer和consumer的config里加入

1
2
3
props.put("sasl.kerberos.service.name", "kafka");
props.put("sasl.mechanism", " GSSAPI");
props.put("security.protocol", "SASL_PLAINTEXT");
对于java程序配置到以上步骤就可以了，以下步骤可以跳过。
对于命令行工具，比如kafka-console-consumer 或 kafka-console-producer，kinit连同 “useTicketCache=true”使用，如：

1
2
3
4
KafkaClient {
com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=true;
};
4.3.2 通过JAAS作为JVM参数（每个客户端的JVM）
在/opt/cloudera/parcels/KAFKA/lib/kafka/bin/kafka-run-class.sh文件中JVM performance options参数的KAFKA_JVM_PERFORMANCE_OPTS中加入

1
-Djava.security.auth.login.config=/etc/kafka/kafka_client_jaas.conf
4.3.3 生成producer.properties和consumer.properties文件
在/etc/kafka/conf/目录下生成producer.properties和consumer.properties

1
2
3
security.protocol=SASL_PLAINTEXT (or SASL_SSL)
sasl.mechanism=GSSAPI
sasl.kerberos.service.name=kafka
4.3.4 使用命令行工具进行生产消费
本文档中使用到的kafka parcel版本为2.0.2-1.2.0.2.p0.5，部署kerberos后，要使用新生产者：

1
kafka-console-producer --broker-list 172.16.18.201:9092 –topic test --producer.config config/producer.properties
新消费者：

1
kafka-console-consumer --bootstrap-server 172.16.18.201:9092 --topic test --new-consumer --from-beginning --consumer.config config/consumer.properties
5. HDFS权限控制

5.1HDFS启用 ACL
默认情况下，ACL 在集群上被禁用。要启用，将 dfs.namenode.acls.enabled 属性设为 true（在 NameNode 的 hdfs-site.xml 中）。

1
dfs.namenode.acls.enabled-->TRUE
5.2使用 Cloudera Manager 启用 HDFS-Sentry 插件
1. 在服务范围类别下，转到安全。
2. 选中启用 Sentry 同步复选框。
3 .使用 Sentry 同步路径前缀属性列出应强制实施 Sentry 权限前缀的 HDFS 路径。可以指定多个 HDFS 路径前缀。默认情况下，该属性指向 user/hive/warehouse 并且必须始终为非空。此处列出的 HDFS 地区以外的表就不会出现 HDFS 权限同步。
4. 单击保存更改。
5. 重新启动群集。请注意，在群集重新启动后，可能还需要两分钟让权限同步生效。
5.3测试 Sentry 同步插件
直接在 HDFS 中访问表文件。例如：
列出文件夹中的文件，并验证在 HDFS（包括 ACL）中显示的文件权限是否与 Sentry 中配置的相匹配。
运行科访问这些文件的 MapReduce、Pig 或 Spark 作业。选择除 HiveServer2 和 Impala 以外的任何工具。
6. Kafka权限控制
6.1启动kafka acl
6.1.1在cm主页中点击kafka，点击配置 > 高级

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

6.1.2 配置kakfa.properties的kafka Broker高级配置代码段（安全阀）

1
2
authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
super.users=User:kafka;
User:kafka默认对应principal:[email protected](超级账户，具有为其他账户赋予权限的权利) 
6.2 命令行界面
6.2.1 kafka-acl支持选项
　　Kafka认证管理CLI（和其他所有的CLI）可以在bin目录中找到。CLI脚本名是kafka-acls.sh。以下列出了所有脚本支持的选项：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
选项  描述  默认  类型选择
--add   添加一个acl Action
--remove    移除一个acl Action
--list  列出acl   Action
--authorizer    Authorizer的完全限定类名   Kafka.security.auth.
SimpleAclAuthorizer Configuration
--authorizer
-properties Key=val,传给authorizer进行初始化，例如：zookeeper.connect=localhost:2181   Configuration
--cluster   指定集群作为资源。   Resource
--topic
[topic name]    指定topic作为资源 Resource
--group
[group-name]    指定consumer-group作为资源
Resource
--allow
-principal  添加到允许访问的ACL中，Principal是Principal Type:name格式，可以指定多个 Principal
--deny
-principal  添加到拒绝访问的ACL中，Principal是Principal Type:name格式，可以指定多个 Principal
--allow-host    --allow-principal中的princiapl的IP的地址被访问。  如果--allow-principal指定的默认值是*，则意味着指定“所有主机”    Host
--deny-host --deny-principal中的princiapl的IP的地址被访问。   如果--allow-principal指定的默认值是*，则意味着指定“所有主机”    Host
--produce   为producer角色添加/删除acl。生成acl，允许在topic上WRITE, DESCRIBE和CREATE集群。    Convenience
--consumer  为consumer角色添加/删除acl。生成acl，允许在topic上READ, DESCRIBE和consumer-group上READ。  Convenience

6.2.2 添加acl
　　假设你要添加一个acl “允许198.51.100.0和User:Alice对主题是Test-Topic有Read和Write的执行权限” 。通过执行下列选项

1
2
kafka-acls --authorizer-properties zookeeper.connect=172.16.18.201:2181/kafka
--add --allow-principal User:Alice --allow-host 172.16.18.202 ---operation Read --operation Write --topic Test-topic
　　默认情况下，所有的principal在没有一个明确的对资源操作访问的acl都是拒绝访问的。在极少的情况下，定义了acl允许访问所有，但一些principal我们将必须使用 --deny-principal 和 --deny-host选项。例如，如果我们想让所有用户读取Test-topic，只拒绝IP为198.51.100.3的User:BadBob，我们可以使用下面的命令:

1
2
3
kafka-acls --authorizer-properties zookeeper.connect=172.16.18.201:2181/kafka
--add --allow-principal User:* --allow-host * --deny-principal
User:BadBob --deny-host 198.51.100.3 --operation Read --topic Test-topic
　　需要注意的是--allow-host和deny-host仅支持IP地址（主机名不支持）。上面的例子中通过指定--topic [topic-name]作为资源选项添加ACL到一个topic。同样，用户通过指定--cluster和通过指定--group [group-name]消费者组添加ACL。
6.2.3 删除acl
　　删除和添加是一样的，--add换成--remove选项，要删除第一个例子中添加的，可以使用下面的命令：

1
kafka-acls --authorizer-properties zookeeper.connect=172.16.18.201:2181/kafka --remove --allow-principal User:Alice --allow-host 172.16.18.202 --operation Read --operation Write --topic Test-topic
6.2.4 acl列表
　　我们可以通过指定与资源--list选项列出任何资源的ACL,alc列表存储在zookeeper中。要列出Test-topic，我们可以用下面的选项执行CLI所有的ACL：

1
kafka-acls --authorizer-properties zookeeper.connect=172.16.18.201:2181/kafka --list --topic Test-topic
6.2.5 添加或删除作为生产者或消费者的principal
　　acl管理添加/移除一个生产者或消费者principal是最常见的使用情况，所以我们增加更便利的选项处理这些情况。为主题Test-topic添加一个生产者User:Alice，我们可以执行以下命令的生产：

1
2
kafka-acls --authorizer-properties zookeeper.connect=172.16.18.201:2181/kafka
--add --allow-principal User:Alice --producer --topic Test-topic
　　同样，添加Alice作为主题Test-topic的消费者，用消费者组为Group-1，我们只用 --consumer 选项：

1
2
kafka-acls --authorizer-properties zookeeper.connect=172.16.18.201:2181/kafka
--add --allow-principal User:Bob --consumer --topic test-topic --group Group-1
　　注意，消费者的选择，我们还必须指定消费者组。从生产者或消费者角色删除主体，我们只需要通过--remove选项。
--------------------- 

转载于:https://my.oschina.net/hblt147/blog/2988188