近日在某項目部署實施過程中，進行了線上漏洞掃描后，在出具的漏掃報告中存在一個需修復項“Zookeeper 未授權訪問”。通過查詢了解，得知需通過添加身份認證的方式來解決該修復項，在修復、驗證以及后續應用上線的過程中，碰到了系列問題，特作記錄分享。

一、 問題介紹

Zookeeper是分布式協同管理工具，常用來管理系統配置信息，提供分布式協同服務。Zookeeper以樹狀結構保存數據，znode是Zookeeper的基本單元，可以存放數據信息、版本信息等等。如下圖，/是Zookeeper的根節點，A、B、C和D均為znode。

Zookeeper這樣的樹狀結構，在默認情況下，只需要提供Zookeeper服務端的IP和Port信息，任何用戶或者客戶端都可以直接連接服務端，不需要任何額外的認證，就擁有對znode增、刪、改、查、管理等操作權限。這樣的訪問方式是非常不安全，比較容易受到攻擊和數據的篡改。

二、 Zookeeper使用ACL進行訪問控制

鑒于存在這樣的安全隱患，Zookeeper通過ACL(Access Control List)的機制來解決這個問題。當客戶端連接到Zookeeper并且做認證的時候，Zookeeper驗證所有從連接的服務端收集到的id，當服務端試圖訪問不同的znode節點時，將通過ACL來做驗證。

ACL是由(scheme:expression, perms)對構成，expression的格式為如下內置schemes：

a. world 有一個特定的的id, anyone，代表所有人。

b. auth 不使用任何id，代表任何已認證的用戶。

c. digest 用 username:password 字符串來產生一個MD5串，然后該串被用來作為ACL ID。認證是通過明文發送username:password 來進行的，當用在ACL時，表達式為username:base64 ，base64是password的SHA1摘要的編碼。

d. ip 使用客戶端的主機IP作為ACL ID 。

Perms的格式為如下操作權限：

a. CREATE：可以創建子節點，縮寫為C;

b. DELETE：可以獲取節點下的數據以及目錄下的列表，縮寫為D;

c. WRITE：可以在節點中寫入數據，縮寫為W;

d. DELETE：可以刪除子節點，縮寫為D：

e. ADMIN：可以設置權限，縮寫為A;

這里有一點需要注意的是，ACL只適用于當前節點，它是非遞歸的，而且是不可遞歸的。比如/aaa節點對用戶aaa只讀，但是/aaa/bbb節點，對所有用戶來說是world的認證方式。

三、 Zookeeper權限配置

通過文檔了解后，擬嘗試使用digest的認證方式作為漏洞的修復手段。

首先登錄Zookeeper控制臺，如下圖所示：

獲取當前目錄權限：

由于該服務器是已修復的，因此顯示的是digest認證的信息。

重新在根目錄下創建目錄：

從這個步驟可以看出，ACL的認證是非遞歸的，即使根目錄的權限是digest，創建的子目錄權限仍然是world。

下圖通過setAcl的命令來設置新目錄的權限，并且查看是生效的。

當登錄后未使用digster認證時，就會提示權限不足。

四、 應用調用修改

既然提供服務的Zookeeper增加了認證，那么調用的java程序也是需要進行同步修改的。

按公司應用的結構，只需要添加對應配置即可。

另外在調試過程中發現，公司使用的第三方jar包zkclient.jar的版本是0.1，是不支持ACL的，需更換成高版本2.0即可。

作者介紹

陳旭，資深應用維護工程師，畢業于浙江大學軟件工程學院，通過ITIL認證。先后在互聯網創業公司、地方電子口岸任職。主要負責中間件運維和自動化運維工具研發，致力于提升運維服務的規范性和應用服務的高可用性。