技術標籤：配置kerberos

背景

目前叢集開啟kerberos大概分為兩種：一種是在建立叢集的時候，同步開啟kerberos認證；還有一種就是叢集部署完成之後，再手動開啟kerberos認證。隨著kerberos認證在現場中使用頻率愈來愈高，問題也是頻發不斷。最近有客戶反饋叢集開啟了kerberos認證，zookeeper的sasl安全管理存在問題。

問題大概描述如下：

1. zookeeper client進行sasl認證，如果jaas檔案和keytab檔案及principal都ok，可以連線成功，正常使用。

2. zookeeper client進行sasl認證，如果jaas檔案和keytab檔案及principal有不ok的，連線不成功，不能正常使用。

3. zookeeper client不進行sasl認證，直接連線，可以連線成功，正常使用。

問題定位

關於這一塊的疑問，社群也是討論了一波。認證的目的肯定是為了做許可權管理，不認證也能連線，怎麼進行許可權管理？有人說這是bug，社群並不予以支援。詳細的描述在ZOOKEEPR-1736中，比較關鍵的一段描述如下：

https://issues.apache.org/jira/browse/ZOOKEEPER-1736

BecauseZKauthenticationispluggable(therefore,SASLisonlyonepossibleoptionoutofseveral)andauthmethodisspecifiedperACL,itisstrictlyspeakingincorrecttorejectconnectionsthatdon'tauthwithSASL,becausetheymightbeabletoauthwithanothermethodtoaccessznodesthatdonothave"sasl"authspecifiedasauthmethod.ThiswasthethinkingwhenSASLintegrationforZKwasdeveloped.OtherwisewewouldhavewrappedthewholeconnectionwithSASL,nottunneledSASLauthinsidetheZKprotocol.So this not a "security issue" as such - it is a deliberate design choice.On the other hand, providing some additional configuration toggle to enforce SASL authentication exclusively can be done. If the ZK devs want to commit it. TLS authentication doesn't work this way. When you use TLS if you can't auth at connection setup it doesn't matter what auth methods are specified by ACLs. In this sense, security design in ZK is inconsistent.
 

大概意思就是說zookeeper認證是外掛化的，sasl只是認證方式中的一種，zookeeper sasl認證允許匿名使用者登入，意思就是說這玩意就是這麼設計的。認證肯定是用來對zookeeper做許可權管理的。但是對於指定節點目錄的許可權管理，還需要結合其對應的ACL配置使用。

比如：在開啟kerberos叢集中，kafka服務在zookeeper中使用的一些節點目錄，其ACL直接設定為anyone可以讀(r)，但是隻有程序sasl認證的kafka使用者才有全部許可權(cdrwa)。從這一點來講，kafka用zookeeper儲存的內容也實現了許可權管理的效果。

準確的說，所有zookeeper client都進行了sasl認證，只不過不載入jaas檔案時候，是sasl認證失敗，自動跳過轉為嘗試直接連線的方式。

不停的去檢測認證雖然對功能沒有什麼影響，但是比較耗費伺服器效能，可以通過設定系統引數(zookeeper.client.sasl)為false來禁用sasl認證。

這一點在社群的ZOOKEEPER-1657有詳細的描述 https://issues.apache.org/jira/browse/ZOOKEEPER-1657