● 系統環境說明
Linux環境:centos7.4
CDH:5.16.1
Java:1.8.0_131
Kerberos版本:1.15.1
● 集群配置
機器數量:50
內存:64G
硬盤:4T
CPU核心數:32
Kerberos部署
安裝
cdh01.ali.aiwaystack.com作為Kerberos主節點安裝服務:
yum install krb5-server -y
其他子節點安裝krb5-devel、krb5-workstation :
yum install krb5-devel krb5-workstation -y
修改配置文件
kdc服務器包含三個配置文件:
# 集群上所有節點都有這個文件而且內容同步 /etc/krb5.conf # 主服務器上的kdc配置 /var/kerberos/krb5kdc/kdc.conf # 能夠不直接訪問 KDC 控制台而從 Kerberos 數據庫添加和刪除主體,需要添加配置 /var/kerberos/krb5kdc/kadm5.acl
修改/etc/krb5.conf為以下內容
# Configuration snippets may be placed in this directory as well includedir /etc/krb5.conf.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = CDH.AI.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 86400 renew_lifetime = 604800 forwardable = true rdns = false pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt [realms] CDH.AI.COM = { kdc = cdh01.ali.aiwaystack.com admin_server = cdh01.ali.aiwaystack.com default_domain = cdh01.ali.aiwaystack.com } [domain_realm] .cdh.ai.com = CDH.AI.COM cdh.ai.com = CDH.AI.COM
配置項說明:
● [logging]:日志輸出設置
● [libdefaults]:連接的默認配置
● default_realm:Kerberos應用程序的默認領域,所有的principal都將帶有這個領域標志
● ticket_lifetime: 表明憑證生效的時限,一般為24小時
● renew_lifetime: 表明憑證最長可以被延期的時限,一般為一個禮拜。當憑證過期之后,對安全認證的服務的后續訪問則會失敗
● clockskew:時鍾偏差是不完全符合主機系統時鍾的票據時戳的容差,超過此容差將不接受此票據。通常,將時鍾扭斜設置為 300 秒(5 分鍾)。這意味着從服務器的角度看,票證的時間戳與它的偏差可以是在前后 5 分鍾內
● udp_preference_limit= 1:禁止使用 udp 可以防止一個 Hadoop 中的錯誤
● [realms]:列舉使用的 realm
● kdc:代表要 kdc 的位置。格式是 機器:端口
● admin_server:代表 admin 的位置。格式是 機器:端口
● default_domain:代表默認的域名
● [domain_realm]:域名到realm的關系
修改/var/kerberos/krb5kdc/kdc.conf
[kdcdefaults] kdc_ports = 88 kdc_tcp_ports = 88 [realms] CDH.AI.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 camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal }
修改/var/kerberos/krb5kdc/kdc.conf
配置項說明:
● [kdcdefaults]:kdc相關配置,這里只設置了端口信息
● [realms]:realms的配置
● CDH.AI.COM:設定的realms領域
● master_key_type:和 supported_enctypes 默認使用 aes256-cts。JAVA 使用 aes256-cts 驗證方式需要安裝 JCE 包
● acl_file:標注了 admin 的用戶權限,文件格式是:Kerberos_principal permissions [target_principal] [restrictions]
● supported_enctypes:支持的校驗方式
● admin_keytab:KDC 進行校驗的 keytab
安裝JCE包需要到Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for JDK/JRE 8
這個網址下載,解壓之后到$JAVA_HOME/jre/lib/security目錄
創建/var/kerberos/krb5kdc/kadm5.acl,內容為:
*/admin@CDH.AI.COM *
配置文件詳細的說明參考官網
創建Kerberos數據庫
# 保存路徑為/var/kerberos/krb5kdc 如果需要重建數據庫,將該目錄下的principal相關的文件刪除即可 kdb5_util create -r CDH.AI.COM -s
-r指定配置的realm領域名
出現 Loading random data 的時候另開個終端執行點消耗CPU的命令如 cat /dev/vda > /dev/urandom 可以加快隨機數采集
該命令會在 /var/kerberos/krb5kdc/ 目錄下創建 principal 數據庫
啟動服務
chkconfig --level 35 krb5kdc on
chkconfig --level 35 kadmin on
systemctl start krb5kdc
systemctl start kadmin
創建Kerberos管理員
# 需要設置兩次密碼,當前設置為root kadmin.local -q "addprinc admin/admin"
principal的名字的第二部分是admin,那么該principal就擁有administrative privileges
這個賬號將會被CDH用來生成其他用戶/服務的principal
測試Kerberos
# 列出Kerberos中的所有認證用戶,即principals kadmin.local -q "list_principals" # 添加認證用戶,需要輸入密碼 kadmin.local -q "addprinc dy" # 使用該用戶登錄,獲取身份認證,需要輸入密碼 kinit dy # 查看當前用戶的認證信息ticket klist # 更新ticket kinit -R # 銷毀當前的ticket kdestroy # 刪除認證用戶 kadmin.local -q "delprinc dy"
抽取密鑰並將其儲存在本地 keytab 文件 /etc/krb5.keytab 中。這個文件由超級用戶擁有,所以必須是 root 用戶才能在 kadmin shell 中執行以下命令:
kadmin.local -q "ktadd kadmin/admin" # 查看生成的keytab klist -k /etc/krb5.keytab
CDH集成Kerberos
為 Cloudera Manager Server獲取或創建Kerberos主體
為了能在集群中創建和部署host principals和keytabs,Cloudera Manager Server必須有一個Kerberos principal來創建其他的賬戶。
如果一個principal的名字的第二部分是admin(例如, cloudera-scm/admin@CDH.AI.COM),那么該principal就擁有administrative privileges。
在KDC server主機上,創建一個名為[cloudra-scm]的principal,並為其設置密碼。執行命令:
[root@cdh01 ~]# kadmin.local
Authenticating as principal root/admin@CDH.AI.COM with password.
Kadmin.local: addprinc -pw admin cloudera-scm/admin@CDH.AI.COM
WARNING: no policy specified for cloudera-scm/admin@CDH.AI.COM; defaulting to no policy
Principal "cloudera-scm/admin@CDH.AI.COM" created.
輸入listprincs可以看到創建了一個名為cloudera-scm/admin@CDH.AI.COM的principal:
導入KDC Account Manager憑據
- 在 Cloudera Manager Admin Console 中,選擇:
管理 > 安全 > Kerberos憑據 > 導入 Kerberos Account Manager 憑據
- 在導入 Kerberos Account Manager 憑據對話框中,針對可以在 KDC 中為 CDH 群集創建主體的用戶輸入用戶名和密碼。
重點:用戶名中,“/”前后都屬於用戶名部分,“/”及后面的admin都不可省略,否則會驗證不通過。
在cloudera Manager Admin Console中配置Kerberos默認領域
- 在 Cloudera Manager Admin Console 中,選擇:
管理 > 安全 > Kerberos憑據 > 配置
- 單擊Kerberos類別,然后在 Kerberos 安全領域字段中為群集輸入您在 krb5.conf 文件中配置的 Kerberos 領域、KDC Server主機、Kerberos加密類型
此處僅貼出有改動部分:
- 單擊保存更改
停止所有服務
-
在主頁上,單機集群名稱右側的
,停止所有服務。
-
在主頁上,單擊 Cloudera Management Service 右側的
,選擇停止。
啟用 HDFS安全性
-
點擊主頁上的HDFS,選擇配置
-
修改下面參數
hadoop.security.authentication ---> kerberos
hadoop.security.authorization ---> true
dfs.datanode.data.dir.perm ---> 700
dfs.datanode.address ---> 1004
dfs.datanode.http.address ---> 1006
- 單擊保存更改
啟用HBASE安全性
-
點擊主頁上的HBASE,選擇配置
-
修改下面參數
hbase.security.authentication ---> Kerberos
hbase.security.authorization ---> true
- 單擊保存
啟用kafka安全性
-
單擊主頁上的kafka,選擇配置
-
修改下面參數
kerberos.auth.enable ---> true
security.inter.broker.protocol ---> SASL_PLAINTEXT
- 單擊保存
kafka使用SASL驗證
kafka目前支持的機制有GSSAPI(Kerberos)和PLAIN ,在以上步驟中,Kafka brokers的SASL已配置,接下來配置Kafka客戶端
- 生成jaas文件
客戶端(生產者,消費者,connect,等等)用自己的principal認證集群(通常用相同名稱作為運行客戶端的用戶)。因此,獲取或根據需要創建這些principal。然后,為每個principal創建一個JAAS文件,KafkaClient描述了生產者和消費者客戶端如何連接到broker。下面是一個客戶端使用keytab的配置例子(建議長時間運行的進程)。在/etc/kafka/目錄下創建kafka_client_jaas.conf文件
KafkaClient {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
storeKey=true
keyTab="/etc/kafka/conf/kafka_client.keytab"
principal="dy/kafka@CDH.AI.COM";
};
創建dy/kafka@CDH.AI.COM
kadmin: addprinc -randkey dy/kafka@CDH.AI.COM
kadmin: xst -k /etc/kafka/conf/kafka_client.keytab dy/kafka@CDH.AI.COM
在使用producer和consumer java接口時,要在代碼main方法中,加入
System.setProperty(“java.security.auth.login.config”,”/etc/kafka/kafka_client_jaas.conf”);
保證程序可以讀取到jaas文件。
在producer和consumer的config里加入
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”使用,如:
KafkaClient {
com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=true;
};
- 通過JAAS作為JVM參數(每個客戶端的JVM)
在/opt/cloudera/parcels/KAFKA/lib/kafka/bin/kafka-run-class.sh文件中JVM performance options參數的KAFKA_JVM_PERFORMANCE_OPTS中加入
-Djava.security.auth.login.config=/etc/kafka/kafka_client_jaas.conf
- 生成producer.properties和consumer.properties文件
在/etc/kafka/conf/目錄下生成producer.properties和consumer.properties
security.protocol=SASL_PLAINTEXT (or SASL_SSL)
sasl.mechanism=GSSAPI
sasl.kerberos.service.name=kafka
- 使用命令行工具進行生產消費
部署kerberos后,要使用新生產者:
kafka-console-producer --broker-list 10.100.11.1:9092 –topic test --producer.config config/producer.properties
新消費者:
kafka-console-consumer --bootstrap-server 10.100.11.1:9092 --topic test --new-consumer --from-beginning --consumer.config config/consumer.properties
啟用zookeeper安全性
-
單擊主頁上的zookeeper,選擇配置
-
修改下面參數
enableSecurity ---> true
等待“生成憑據”命令完成
在 Cloudera Manager 中為任何服務啟用安全保護之后,將自動觸發稱為“生成憑據”的命令。您可以在顯示正在運行的命令的屏幕右上角看到該命令的進度。請等待此命令完成(通過內含“0”的灰色框表示)。
使 Hue 能夠使用 Cloudera Manager 與 Hadoop 安全一起工作
如果您使用的是 Hue 服務,那么您必須向 Hue 服務添加 Kerberos Ticket Renewer 的角色實例,以使 Hue 能夠使用 Cloudera Manager 與安全的 Hadoop 群集一起正常工作,否則集群會持續報致命錯誤。
Hue Kerberos Ticket Renewer 僅為主體 hue/
- 轉到Hue服務。
- 單擊實例選項卡。
- 單擊添加角色實例按鈕。
- 為與Hue Server相同的主機分配Kerberos Ticket Renewer序角色實例。
- 在向導完成后,狀態將顯示已完成,並且 Kerberos Ticket Renewer 角色實例已配置。Hue 服務現在將與安全的 Hadoop 群集一起工作。
注:此處可能會報Couldn't renew kerberos ticket的錯誤
[10/Feb/2020 23:41:17 -0800] kt_renewer INFO Renewing kerberos ticket to work around kerberos 1.8.1: /bin/kinit -R -c /var/run/hue/hue_krb5_ccache
[10/Feb/2020 23:41:17 -0800] kt_renewer ERROR Couldn't renew kerberos ticket in order to work around Kerberos 1.8.1 issue. Please check that the ticket for 'hue/cdh02.ali.aiwaystack.com@CDH.AI.COM' is still renewable:
$ klist -f -c /var/run/hue/hue_krb5_ccache
If the 'renew until' date is the same as the 'valid starting' date, the ticket cannot be renewed. Please check your KDC configuration, and the ticket renewal policy (maxrenewlife) for the 'hue/cdh02.ali.aiwaystack.com@CDH.AI.COM' and `krbtgt' principals.
[11/Feb/2020 15:44:19 ] settings INFO Welcome to Hue 3.9.0
[10/Feb/2020 23:44:21 -0800] __init__ INFO Couldn't import snappy. Support for snappy compression disabled.
[10/Feb/2020 23:44:21 -0800] kt_renewer INFO Reinitting kerberos retry attempt 0 from keytab /bin/kinit -k -t /opt/cloudera-manager/cm-5.16.1/run/cloudera-scm-agent/process/1297-hue-KT_RENEWER/hue.keytab -c /var/run/hue/hue_krb5_ccache hue/cdh02.ali.aiwaystack.com@CDH.AI.COM
[10/Feb/2020 23:44:22 -0800] kt_renewer INFO Renewing kerberos ticket to work around kerberos 1.8.1: /bin/kinit -R -c /var/run/hue/hue_krb5_ccache
[10/Feb/2020 23:44:22 -0800] kt_renewer ERROR Couldn't renew kerberos ticket in order to work around Kerberos 1.8.1 issue. Please check that the ticket for 'hue/cdh02.ali.aiwaystack.com@CDH.AI.COM' is still renewable:
$ klist -f -c /var/run/hue/hue_krb5_ccache
If the 'renew until' date is the same as the 'valid starting' date, the ticket cannot be renewed. Please check your KDC configuration, and the ticket renewal policy (maxrenewlife) for the 'hue/cdh02.ali.aiwaystack.com@CDH.AI.COM' and `krbtgt' principals.
[11/Feb/2020 15:44:24 ] settings INFO Welcome to Hue 3.9.0
[10/Feb/2020 23:44:26 -0800] __init__ INFO Couldn't import snappy. Support for snappy compression disabled.
[10/Feb/2020 23:44:26 -0800] kt_renewer INFO Reinitting kerberos retry attempt 0 from keytab /bin/kinit -k -t /opt/cloudera-manager/cm-5.16.1/run/cloudera-scm-agent/process/1297-hue-KT_RENEWER/hue.keytab -c /var/run/hue/hue_krb5_ccache hue/cdh02.ali.aiwaystack.com@CDH.AI.COM
[10/Feb/2020 23:44:28 -0800] kt_renewer INFO Renewing kerberos ticket to work around kerberos 1.8.1: /bin/kinit -R -c /var/run/hue/hue_krb5_ccache
[10/Feb/2020 23:44:28 -0800] kt_renewer ERROR Couldn't renew kerberos ticket in order to work around Kerberos 1.8.1 issue. Please check that the ticket for 'hue/cdh02.ali.aiwaystack.com@CDH.AI.COM' is still renewable:
$ klist -f -c /var/run/hue/hue_krb5_ccache
If the 'renew until' date is the same as the 'valid starting' date, the ticket cannot be renewed. Please check your KDC configuration, and the ticket renewal policy (maxrenewlife) for the 'hue/cdh02.ali.aiwaystack.com@CDH.AI.COM' and `krbtgt' principals.
此問題官方給出了解決方案:
即:
root@cdh01 ~
> # kadmin.local
Authenticating as principal root/admin@CDH.AI.COM with password.
kadmin.local: modprinc -maxrenewlife 90day krbtgt/CDH.AI.COM@CDH.AI.COM
Principal "krbtgt/CDH.AI.COM@CDH.AI.COM" modified.
kadmin.local: modprinc -maxrenewlife 90day +allow_renewable hue/cdh02.ali.aiwaystack.com@CDH.AI.COM
Principal "hue/cdh02.ali.aiwaystack.com@CDH.AI.COM" modified.
啟動所有服務
啟動所有服務,在主頁上,單擊群集名稱右側的 並選擇啟動。
啟動 Cloudera Management Service,在主頁上,單擊Cloudera Management Service右側的並選擇啟動。
部署客戶端配置
在主頁,單擊群集名稱右側的,並選擇部署客戶端配置。
創建 HDFS 超級用戶主體
要為用戶創建主目錄,您需要對超級用戶帳戶具有訪問權限。在 HDFS 中,運行 NameNode 進程的用戶帳戶(默認情況下為 hdfds)是一個超級用戶。在安裝 CDH 的過程中,CDH 會自動在每個群集主機上創建 hdfs 超級用戶帳戶。當為 HDFS 服務啟用 Kerberos 時,您無法通過 su - hdfs 命令訪問 hdfs 超級用戶帳戶。要在 Kerberos 處於啟用狀態時能夠訪問 hdfs 超級用戶帳戶,您必須創建一個 Kerberos 主體或 AD 用戶,並且其第一個或唯一一個組成部分必須是 hdfs。或者,您也可以指定其成員屬於超級用戶的超級用戶組。
在kadmin.local中,鍵入以下命令來創建名為hdfs的Kerberos主體:
root@cdh01 ~
> # kadmin.local
Authenticating as principal root/admin@CDH.AI.COM with password.
kadmin.local: addprinc hdfs@CDH.AI.COM
WARNING: no policy specified for hdfs@CDH.AI.COM; defaulting to no policy
Enter password for principal "hdfs@CDH.AI.COM":
Re-enter password for principal "hdfs@CDH.AI.COM":
Principal "hdfs@CDH.AI.COM" created.
此命令會提示您為 hdfs 主體創建密碼。請使用強密碼,因為此主體對 HDFS 中的所有文件提供超級用戶訪問權限。
要作為 hdfs 超級用戶運行命令,您必須為 hdfs 主體獲取 Kerberos 憑據。要執行此操作,請運行以下命令並提供密碼:
root@cdh01 ~
> # kinit hdfs@CDH.AI.COM