CDH 的Kerberos认证配置

时间  2019-11-24
标签 cdh kerberos 认证 配置 繁體版
原文   原文链接

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

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

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

配置kdc集群的先解决条件mysql

server 主机配置以下linux

1.主配hosts置文件以下（全部机器）sql

cat /etc/hostsshell

192.168.237.230  masternode01数据库

192.168.237.231  masternode02apache

192.168.237.232  slavenode02bootstrap

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

*/admin@HADOOP.COM*

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/admin@HADOOP.COM


配置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 root@192.168.237.2$i:/etc/;done

9.验证KDC是否生效

[root@masternode01 ~]# kadmin

Authenticating as principal admin/admin@HADOOP.COM with password.

Password for admin/admin@HADOOP.COM: 

kadmin:

其余客户端验证方法以下：

[root@slavenode04 ~]# kinit admin/admin

Password for admin/admin@HADOOP.COM: 

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/admin@HADOOP.COM with password.

Password for admin/admin@HADOOP.COM: 

kadmin:

kadmin:  addprinc cloudera-scm/admin

WARNING: no policy specified for test@HADOOP.COM; defaulting to no policy

Enter password for principal "cloudera-scm@HADOOP.COM": 输入密码必定要记住

Re-enter password for principal "cloudera-scm@HADOOP.COM": 

Principal "cloudera-scm@HADOOP.COM" 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

 

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

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

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

 

2、环境说明

一、主机名

以前部署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的解析。

 

二、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

 

三、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加密，方法见官方文档对应的部分。

 

3、部署KDC

一、安装kdc server

只须要在kdc中安装

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

 

二、配置文件

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 *

三、建立数据库

 

  1. #kdb5_util create -r for_hadoop -s

 

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

 

四、关于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

 

五、建立远程管理的管理员

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

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

 

六、建立测试用户

  1. #kadmin.local
  2. addprinc test

 

七、经常使用kerberos管理命令

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

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

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

九、测试

使用以前建立的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登录成功。

 

4、为hadoop建立认证规则（Principals）和keytab

一、一些概念

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

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

对于hadoop，principals的格式为username/fully.qualified.domain.name@YOUR-REALM.COM.

 

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

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

由于服务器上能够访问keytab文件便可以以principal的身份经过kerberos的认证，因此，keytab文件应该被妥善保存，应该只有少数的用户能够访问。

 

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

 

二、为集群中每一个服务器节点添加三个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

三、建立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/fully.qualified.domain.name@YOUR-REALM.COM (DES cbc mode with CRC-32)
  7. 2 7 host/fully.qualified.domain.name@YOUR-REALM.COM (Triple DES cbc mode with HMAC/sha1)
  8. 3 7 hdfs/fully.qualified.domain.name@YOUR-REALM.COM (DES cbc mode with CRC-32)
  9. 4 7 hdfs/fully.qualified.domain.name@YOUR-REALM.COM (Triple DES cbc mode with HMAC/sha1)

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

 

  1. # kinit -k -t hdfs.keytab hdfs/fully.qualified.domain.name@YOUR-REALM.COM
  2. # kinit -k -t hdfs.keytab host/fully.qualified.domain.name@YOUR-REALM.COM

若是出现错误：

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

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

 

四、部署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失败的问题，首先须要检查的就是文件的权限。

 

5、中止hadoop集群

 

6、Enable Hadoop Security

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

  1. <property>
  2.   <name>hadoop.security.authentication</name>
  3.   <value>kerberos</value> <!-- A value of "simple" would disable security. -->
  4. </property>
  5.  
  6. <property>
  7.   <name>hadoop.security.authorization</name>
  8.   <value>true</value>
  9. </property>

7、Configure Secure HDFS一、在集群中全部节点的hdfs-site.xml文件中添加下面的配置 

  1. <!-- General HDFS security config -->
  2. <property>
  3.   <name>dfs.block.access.token.enable</name>
  4.   <value>true</value>
  5. </property>
  6.  
  7. <!-- NameNode security config -->
  8. <property>
  9.   <name>dfs.https.address</name>
  10.   <value><fully qualified domain name of NN>:50470</value>
  11. </property>
  12. <property>
  13.   <name>dfs.https.port</name>
  14.   <value>50470</value>
  15. </property>
  16. <property>
  17.   <name>dfs.namenode.keytab.file</name>
  18.   <value>/usr/local/hadoop/conf/hdfs.keytab</value> <!-- path to the HDFS keytab -->
  19. </property>
  20. <property>
  21.   <name>dfs.namenode.kerberos.principal</name>
  22.   <value>hdfs/_HOST@YOUR-REALM.COM</value>
  23. </property>
  24. <property>
  25.   <name>dfs.namenode.kerberos.https.principal</name>
  26.   <value>host/_HOST@YOUR-REALM.COM</value>
  27. </property>
  28.  
  29. <!-- Secondary NameNode security config -->
  30. <property>
  31.   <name>dfs.secondary.https.address</name>
  32.   <value><fully qualified domain name of 2NN>:50495</value>
  33. </property>
  34. <property>
  35.   <name>dfs.secondary.https.port</name>
  36.   <value>50495</value>
  37. </property>
  38. <property>
  39.   <name>dfs.secondary.namenode.keytab.file</name>
  40.   <value>/usr/local/hadoop/conf/hdfs.keytab</value> <!-- path to the HDFS keytab -->
  41. </property>
  42. <property>
  43.   <name>dfs.secondary.namenode.kerberos.principal</name>
  44.   <value>hdfs/_HOST@YOUR-REALM.COM</value>
  45. </property>
  46. <property>
  47.   <name>dfs.secondary.namenode.kerberos.https.principal</name>
  48.   <value>host/_HOST@YOUR-REALM.COM</value>
  49. </property>
  50.  
  51. <!-- DataNode security config -->
  52. <property>
  53.   <name>dfs.datanode.data.dir.perm</name>
  54.   <value>700</value>
  55. </property>
  56. <property>
  57.   <name>dfs.datanode.address</name>
  58.   <value>0.0.0.0:1004</value>
  59. </property>
  60. <property>
  61.   <name>dfs.datanode.http.address</name>
  62.   <value>0.0.0.0:1006</value>
  63. </property>
  64. <property>
  65.   <name>dfs.datanode.keytab.file</name>
  66.   <value>/usr/local/hadoop/conf/hdfs.keytab</value> <!-- path to the HDFS keytab -->
  67. </property>
  68. <property>
  69.   <name>dfs.datanode.kerberos.principal</name>
  70.   <value>hdfs/_HOST@YOUR-REALM.COM</value>
  71. </property>
  72. <property>
  73.   <name>dfs.datanode.kerberos.https.principal</name>
  74.   <value>host/_HOST@YOUR-REALM.COM</value>
  75. </property>

二、启动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/fully.qualified.domain.name@YOUR-REALM.COM using keytab file /etc/hadoop/hdfs.keytab
  1. 10/10/25 17:01:52 INFO security.UserGroupInformation: Login successful for user host/fully.qualified.domain.name@YOUR-REALM.COM 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也不会形成上面的那个问题了。

 

三、验证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了。

 

四、启动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.<init>(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是相同的。

 

五、 Set the Sticky Bit on HDFS Directories.

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

 

8、Start up the Secondary NameNode

跳过

 

9、Configure Secure MapReduce

在mapred-site.xml中添加

 

  1. <!-- JobTracker security configs -->
  2. <property>
  3.   <name>mapreduce.jobtracker.kerberos.principal</name>
  4.   <value>mapred/_HOST@YOUR-REALM.COM</value>
  5. </property>
  6. <property>
  7.   <name>mapreduce.jobtracker.kerberos.https.principal</name>
  8.   <value>host/_HOST@YOUR-REALM.COM</value>
  9. </property>
  10. <property>
  11.   <name>mapreduce.jobtracker.keytab.file</name>
  12.   <value>/usr/local/hadoop/conf/mapred.keytab</value> <!-- path to the MapReduce keytab -->
  13. </property>
  14.  
  15. <!-- TaskTracker security configs -->
  16. <property>
  17.   <name>mapreduce.tasktracker.kerberos.principal</name>
  18.   <value>mapred/_HOST@YOUR-REALM.COM</value>
  19. </property>
  20. <property>
  21.   <name>mapreduce.tasktracker.kerberos.https.principal</name>
  22.   <value>host/_HOST@YOUR-REALM.COM</value>
  23. </property>
  24. <property>
  25.   <name>mapreduce.tasktracker.keytab.file</name>
  26.   <value>/usr/local/hadoop/conf/mapred.keytab</value> <!-- path to the MapReduce keytab -->
  27. </property>
  28.  
  29. <!-- TaskController settings -->
  30. <property>
  31.   <name>mapred.task.tracker.task-controller</name>
  32.   <value>org.apache.hadoop.mapred.LinuxTaskController</value>
  33. </property>
  34. <property>
  35.   <name>mapreduce.tasktracker.group</name>
  36.   <value>mapred</value>
  37. </property>

 

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

<path of task-controller binary>/../../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
　　一、点击“操做”，“添加服务”；
　　二、选择sentry，并“继续”；


 

 

 

 

 

 

 

 

 

 

 

 

 

 

三、选择一组依赖关系


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

五、配置存储数据库；

　　在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;
六、测试链接


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


七、建立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) 无限制强度权限策略文件。可经过两种方法执行此操做：
　　一、 在 Cloudera Manager Admin Console 中，导航到主机页面。向群集添加新主机向导和从新运行升级向导都使您可以选择让 Cloudera Manager 为您安装 JCE 策略文件。
　　二、 您能够按照 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/EXAMPLE.COM@EXAMPLE.COM）。若是在执行全部这些步骤以后仍在使用 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/admin@YOUR-LOCAL-REALM.COM ），那么该principal就拥有administrative privileges。

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

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

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


 

 

 

 

 

 

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

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

 

 

 

 

 

 

 

 

 

 

 

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

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


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

三、 单击保存更改。

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

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
　　三、单击保存更改
4.2.8 启用HBASE安全性
　　一、点击主页上的HBASE，选择配置
　　二、修改下面参数

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

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

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

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

1
2
3
4
<property>
<name>sentry.hive.testing.mode</name>
<value>false</value>
</property>
　　四、选择“范围”中的“HiveServer2”，修改以下配置：

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

1
2
3
4
<property>
<name>hive.security.authorization.task.factory</name>
<value>org.apache.sentry.binding.hive.SentryHiveAuthorizationTaskFactoryImpl</value>
</property>
六、选择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
<property>
<name>hive.metastore.client.impl</name>
<value>org.apache.sentry.binding.metastore.SentryHiveMetaStoreClient</value>
<description>Sets custom Hive Metastore client which Sentry uses to filter out metadata.</description>
</property>
<property>
<name>hive.metastore.pre.event.listeners</name>
<value>org.apache.sentry.binding.metastore.MetastoreAuthzBinding</value>
<description>list of comma separated listeners for metastore events.</description>
</property>
<property>
<name>hive.metastore.event.listeners</name>
<value>org.apache.sentry.binding.metastore.SentryMetastorePostEventListener</value>
<description>list of comma separated listeners for metastore, post events.</description>
</property>
<property>
<name>hive.metastore.filter.hook</name>
<value>org.apache.sentry.binding.metastore.SentryMetaStoreFilterHook</value>
</property>
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
<property>
<name>sentry.service.processor.factories</name>
<value>org.apache.sentry.provider.db.service.thrift.SentryPolicyStoreProcessorFactory,org.apache.sentry.hdfs.SentryHDFSServiceProcessorFactory</value>
</property>
<property>
<name>sentry.policy.store.plugins</name>
<value>org.apache.sentry.hdfs.SentryPlugin</value>
</property>
<property>
<name>sentry.hdfs.integration.path.prefixes</name>
<value>/user/hive/warehouse</value>
</property>
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/<hostname>@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 hdfs@HADOOP.COM
此命令会提示您为 hdfs 主体建立密码。请使用强密码，由于此主体对 HDFS 中的全部文件提供超级用户访问权限。
要做为 hdfs 超级用户运行命令，您必须为 hdfs 主体获取 Kerberos 凭据。要执行此操做，请运行如下命令并提供密码：

1
$ kinit hdfs@HADOOP.COM
指定超级用户组
要指定超级用户组而不使用默认 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 username@HADOOP.COM
4.2.20为每一个用户准备群集
在您和其余用户能够访问群集以前，您必须执行一些任务来为每一个用户准备主机。
1. 确保群集中的全部主机都有一个linux用户账户而且该账户的名称与用户的主体名称的第一个组成部分相同。例如，若是用户的主体名称是 joe@HADOOP.COM，则每一个框中应存在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="kafka-client-1@HADOOP.COM";
};
建立kafka-client-1@HADOOP.COM

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:kafka@HADOOP.COM(超级帐户，具备为其余帐户赋予权限的权利) 
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选项。 --------------------- 

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程