CDH 的Kerberos認證配置

最近由於項目須要,須要對用戶權限作限制,最終選擇了kerberos+sentry+hue模式來管理用戶,可是這個kerberos實在搞得我頭大的不行,在網上找各類資料,怎麼配置都不行,後來索性靜下心來研究官方文檔,在經歷3天的痛苦折騰以後,終於實現了成功啓動kerberos,爲了各位能少走彎路我把個人經驗寫出來,供有緣人借鑑並少走彎路。html

其實本身走了一遍後,真的是很簡單,只是我本身當初想的太複雜,沒有搞清楚cdh的原理,cdh本身都配置好的,我本身只需保證整個集羣KDC組是通的便可,其餘都不須要本身手動操做,如今終於明白了網上那些博客都是本身手動安裝kerberos才須要大量的配置密鑰和建立規則,言歸正傳。java

個人環境很簡單10個節點,個人配置是1個節點作cdh的server+CDH的server是單獨存放監聽的東西,上面hadoop的什麼服務都不放,2個節點作namenode 其他7個節點是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

 

2.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

3.修改/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

 

5.生成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選項。 --------------------- 

相關文章
相關標籤/搜索