楔子

前段時間在研究Zookeeper配置統一管理系統的時候，意外把開發環境的Zookeeper的許可權搞壞了，導致了所有服務都無法把資訊上傳至Zookeeper。由於公司的所有人都共用一套開發環境，如果此時有人需要更新服務，那麼勢必會造成服務無法正常啟動。Zookeeper的許可權修復火速開始了。

正文

首先先看一下正常狀態的Zookeeper許可權設定

[zk: localhost:2181(CONNECTED) 10] ls /
[zookeeper, config]
[zk: localhost:2181(CONNECTED) 11] getAcl /config
'world
 
,'anyone
: r
'ip,'192.168.0.106
: cdrwa
[zk: localhost:2181(CONNECTED) 12]

根節點下有兩個節點一個zookeeper和config，config的訪問許可權對於192.168.0.106下使用者有Zookeeper的完全訪問許可權，而從其他機器進行訪問就只有只讀許可權了。

由於實驗用的Zookeeper配置管理系統並不是放置在192.168.0.106機器下，所以我就對config節點的訪問許可權進行了修改，但是中途出現了錯誤導致config的許可權變成了對所有訪問者都只有只讀許可權（如下所示），這就造成了嚴重的問題，該套環境上的其他同事都無法對config節點下的所有資料進行修改。

[zk: 192.168.0.106(CONNECTED) 3] getAcl /config
'world,'anyone
: r
[zk: 192.168.0.106(CONNECTED) 4]

本著自己弄壞的，自己的修的原則，下面開始了Zookeeper許可權修復的旅程。

進過了一番的折騰，發現只有使用Zookeeper的超級管理員使用者才能對節點許可權進行修復。其實Zookeeper的超級使用者也是為了在發生這種情況下，最後的拯救措施（瞎猜的）。

1. 獲取Zookeeper的超級管理員許可權

首先我們需要先想好Zookeeper的超級管理員登入賬號和密碼，這裡我們設定為super:superman

String m = DigestAuthenticationProvider.generateDigest("super:superman");
System.out.println(m);

輸出為super:SQe25qcxXpeEUnoR1zBktlwk6jA=

下面我們開始設定Zookeeper的超級管理員，在zkServer.sh中找到以下內容

nohup "$JAVA" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \

然後在後面追加以下內容

"-Dzookeeper.DigestAuthenticationProvider.superDigest=super:SQe25qcxXpeEUnoR1zBktlwk6jA="

然後就合併成以下形式

nohup $JAVA "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" "-Dzookeeper.DigestAuthenticationProvider.superDigest=super:SQe25qcxXpeEUnoR1zBktlwk6jA="\  
    -cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT" 2>&1 < /dev/null &  

最後重啟Zookeeper，登入超級管理員

[zk: localhost:2181(CONNECTED) 3] addauth digest super:superman
[zk: localhost:2181(CONNECTED) 4]

這個時候就能隨意的修改節點的許可權

2. Zookeeper的許可權管理

下面我們來講講Zookeeper的許可權管理

2.1 Zookeeper支援的許可權型別

• CREATE: 你可以建立子節點。
• READ: 你可以獲取節點資料以及當前節點的子節點列表。
• WRITE: 你可以為節點設定資料。
• DELETE: 你可以刪除子節點。
• ADMIN: 可以為節點設定許可權。

2.2 Zookeeper支援的許可權設定模式（Scheme）

這裡所有的許可權設定格式都遵循scheme:id:permission

以下為所有的scheme列表

• world：代表所有使用者，該模式下id這裡為一個該固定值，anyone
• digest：該模式下，id為user:pwd，這裡的pwd為編碼過後的值
• auth：該模式下，id為user，表示只有指定使用者具有訪問許可權
• host：該模式下，id為主機名，其中需要注意的是host可以只是主機名的字尾，例如id=corp.com可以匹配 host1.corp.com 和 host2.corp.com 主機名的機器，而主機名為 host1.store.com 的機器是無法匹配的
• ip：該模式與host的模式類似，只不過這裡的ip就是ip地址

2.3 單許可權模式設定

2.3.1 world模式

[zk: 192.168.0.111(CONNECTED) 9] create /config/world null
Created /config/world
[zk: 192.168.0.111(CONNECTED) 10] setAcl /config/world world:anyone:r
[zk: 192.168.0.111(CONNECTED) 12] getAcl /config/world
'world,'anyone
: r
[zk: 192.168.0.111(CONNECTED) 13]

我們在config節點下建立一個world節點，然後為其設定許可權為對於所有人都只有只讀許可權

2.3.2 digest模式

[zk: 192.168.0.111(CONNECTED) 6] create /config/digest null
Created /config/digest
[zk: 192.168.0.111(CONNECTED) 14] setAcl /config/digest digest:user:6DY5WhzOfGsWQ1XFuIyzxkpwdPo=:cdwra
[zk: 192.168.0.111(CONNECTED) 15] getAcl /config/digest
'digest,'user:6DY5WhzOfGsWQ1XFuIyzxkpwdPo=
: cdrwa
[zk: 192.168.0.111(CONNECTED) 2] addauth digest user:123456
[zk: 192.168.0.111(CONNECTED) 3] get /config/digest
null

我們在config節點下建立一個digest節點，然後為其設定許可權為只有使用賬號密碼為user:123456的使用者才有完全的訪問許可權

2.3.3 auth模式

[zk: 192.168.0.111(CONNECTED) 7] create /config/auth null
Created /config/auth
[zk: 192.168.0.111(CONNECTED) 8] addauth digest user:123456
[zk: 192.168.0.111(CONNECTED) 9] setAcl /config/auth auth:user:cdwra
[zk: 192.168.0.111(CONNECTED) 10] getAcl /config/auth
'digest,'user:6DY5WhzOfGsWQ1XFuIyzxkpwdPo=
: cdrwa
[zk: 192.168.0.111(CONNECTED) 11]

我們在config節點下建立一個digest節點，然後新增一個賬號和密碼為user:123456的認證使用者，然後對該使用者新增操作許可權。這個時候我們通過getAcl檢視/config/auth節點的控制權限與上面的/config/digest一模一樣，因此使用auth模式與digest模式的效果是完全一樣的。

2.3.4 ip模式

[zk: 192.168.0.111(CONNECTED) 9] create /config/ip null
Created /config/ip
[zk: 192.168.0.111(CONNECTED) 10] setAcl /config/ip ip:192.168.0.106:cdwra
[zk: 192.168.0.111(CONNECTED) 12] getAcl /config/ip
'ip,'192.168.0.106
: cdrwa
[zk: 192.168.0.111(CONNECTED) 13]

我們在config節點下建立一個ip節點，然後為其設定許可權為只有ip地址為192.168.0.106的使用者才有完全的訪問許可權

2.3.5 host模式

[zk: 192.168.0.111(CONNECTED) 9] create /config/host null
Created /config/host
[zk: 192.168.0.111(CONNECTED) 10] setAcl /config/host host:corp.com:cdwra
[zk: 192.168.0.111(CONNECTED) 12] getAcl /config/host
'host,'corp.com
: cdrwa
[zk: 192.168.0.111(CONNECTED) 13]

我們在config節點下建立一個host節點，然後為其設定許可權為只有主機名為corp.com的使用者才有完全的訪問許可權

2.4 組合許可權模式設定

如果我們需要對Zookeeper的節點進行復雜的許可權設定，例如一開始我們在正文所看到的許可權設定

[zk: localhost:2181(CONNECTED) 11] getAcl /config
'world,'anyone
: r
'ip,'192.168.0.106
: cdrwa

要實現這樣的設定需要執行以下命令

[zk: 192.168.0.111(CONNECTED) 10] setAcl /config world:anyone:r,ip:192.168.0.106:cdrwa

多種許可權設定以逗號分隔開，如果還需要允許以賬號密碼user:123456登入的使用者也擁有config節點的完全訪問許可權則如下設定

[zk: 192.168.0.111(CONNECTED) 12] setAcl /config world:anyone:r,ip:192.168.0.106:cdrwa,digest:user:6DY5WhzOfGsWQ1XFuIyzxkpwdPo=:cdwra

2.5 節點訪問許可權的繼承性

最後我們來講一下Zookeeper節點的許可權是否具有繼承性。其實Zookeeper的Acl準確的來說只是一種訪問控制，並不是完整的許可權管理。由於Acl控制節點並沒有遞迴機制，這就導致了子節點的訪問控制無法繼承父節點的訪問空。下面讓我們通過一個簡單的例子來感受一下。

我們現在在config節點下再建立一個noAcl節點，兩個節點的訪問控制分別如下：

[zk: 192.168.0.111(CONNECTED) 4] getAcl /config
'digest,'user:6DY5WhzOfGsWQ1XFuIyzxkpwdPo=
: cdrwa
[zk: 192.168.0.111(CONNECTED) 5] getAcl /config/noAcl
'world,'anyone
: cdrwa
[zk: 192.168.0.111(CONNECTED) 6]

我們現在不使用user使用者登入，這時候檢視config節點的內容和config下的子節點

[zk: 192.168.0.111(CONNECTED) 6] get /config
Authentication is not valid : /config
[zk: 192.168.0.111(CONNECTED) 7] ls /config
Authentication is not valid : /config
[zk: 192.168.0.111(CONNECTED) 8]

均顯示沒有許可權操作config節點，但是我們現在檢視一下noAcl節點的內容

[zk: 192.168.0.111(CONNECTED) 8] get /config/noAcl
hello

這個時候我們可以很清楚的檢視noAcl節點裡面的內容，如果我們需要保護noAcl節點的話，只能對其單獨設定訪問控制。這個時候大家可能會對Zookeeper的訪問設定抱有一定的質疑。其實我們沒有必要將這種缺陷擴大化。首先Zookeeper中主要放置的都是一些與業務無關的系統配置資訊，其次是對於系統外部使用者而言，如果get不到config節點下的子節點列表，那麼就何談獲取子節點的內容了。如果真的子節點內的資訊比較關鍵，那麼單獨為其進行訪問控制又何嘗不可。

至此本文的所有內容到此結束。現在做一下下期預告，簡要的介紹一下zkCli的使用說明。

歡迎關注微信公眾號，在這裡可以提前看到下一期文章哦~