ZooKeeper zkclient ACL 訪問控制列表
存在的必要性
設計架構
acl 通過 [scheme:id:permissions] 構成
ZK的節點有5種操作許可權：
許可權組合字串
縮寫 crdwa
CREATE：建立子節點
READ：獲取節點、子節點
WRITE：設定節點資料
DELETE：刪除子節點
ADMIN：設定許可權
注：這5種許可權中，delete是指對子節點的刪除許可權，其它4種許可權指對自身節點的操作許可權
4種身份的認證方式：
- world: world下只有一個 id，即只有一個使用者，也就是 anyone，組合寫法為：world:anyone:[permissions]
- auth: 代表認證登入，需要註冊使用者有許可權，形式為：auth:user:password:[permissions],(作用： 1： 通過addauth digest user:pwd 來認證使用者，2 ：可以在1之後，設定節點acl許可權使用。)
-
digest: 需要對密碼加密才能訪問，digest:username:BASE64(SHA1(password)):[permissions]
-
ip: 設定為指定的 ip，此時對 ip 訪問進行限制，ip:192.168.1.1:[permissions]
- super: 代表超級管理員，擁有所有的許可權
id: 認證物件
物件: 根據schema 的不同而不同。
IP物件 ：ip:192.168.1.1
auth 物件： auth:user1:pass1
digest 物件 digest:user1 :base64(sha1("pass1"))
測試示例：
測試功能點：1預設所有的節點都是world:anyone 的訪問控制權限。
Cli命令列下可以這樣測試：
通過getAcl命令可以發現，剛建立的節點，預設是 world,anyone的認證方式，具有cdrwa所有許可權
測試功能點：2 可以通過setAcl 設定許可權 ,getAcl 獲取許可權，獲取許可權得到的祕鑰都是加密過的。設定許可權之後，get 方法獲取某個path 下的資料，就需要 先認證再獲取了，認證是通過addauth 命令實現的。
先給/test增加了user1:+owfoSBn/am19roBPzR1/MfCblE的只讀(r)許可權控制，
說明：setAcl /test digest:使用者名稱:密碼:許可權 給節點設定ACL訪問許可權時，密碼必須是加密後的內容，這裡的+owfoSBn/am19roBPzR1/MfCblE=，對應的原文是12345 (至於這個密文怎麼得來的，後面會講到，這裡先不管這個)，設定完Acl後，可以通過
getAcl /節點路徑 檢視Acl設定
然後get /test時，提示認證無效，說明訪問控制起作用了，接下來：
addauth digest user1:12345 給"上下文"增加了一個認證使用者，即對應剛才setAcl的設定
然後再 get /test 就能取到資料了
最後 delete /test 成功了！原因是：根節點/預設是world:anyone:crdwa(即：全世界都能隨便折騰)，所以也就是說任何人，都能對根節點/進行讀、寫、建立子節點、管理acl、以及刪除子節點（再次映證了ACL中的delete許可權應該理解為對子節點的delete許可權）
測試功能點：3 setAcl /path digest這種方式，必須輸入密碼加密後的值，這在cli控制檯上很不方便，所以可以先認證上下文，然後使用 setacl path 明文許可權 做許可權設定。
注意加框的部分，先用addauth digest user1:12345 增加一個認證使用者，然後用 setAcl /test auth:user1:12345:r 設定許可權，跟剛才的效果一樣，但是密碼這裡輸入的是明文，控制檯模式下手動輸入更方便。
加密規則
好了，揭開加密規則：
|
1 2 3 4 5 6 7 |
|
就是SHA1加密，然後base64編碼
許可權控制和目錄的關係
最後：關於多級節點之間的ACL，並非繼承關係，但是也有些一聯絡，這是初次接觸ACL中比較難理解的地方：
從這張圖上可以發現，子節點/a/b的控制權限範圍（全世界都能做任何事）可以超出父節點的範圍(僅限：user-a:pwd:a具有read/admin許可權)
繼續，看上面的這4條紅線標註的地方，從上向下一個個解釋：
紅線1：因為/a只有user-a:pwd-a有ra許可權，即：沒使用者具有c（create）許可權，所以不能建立子節點
紅線2：因為/a/b為world:anyone:cdrwa許可權，即無限制，所以在/a/b下建立子節點b1，地球人已經無法阻止，建立成功
紅線3：給/a/b/b1指定了user-b1:pwd-b1的da許可權（即：delete+admin）
(注：重溫下前面提到的setAcl 二種模式，
一種是setAcl /path digest:username:encrypedpwd:crwda 用這種方式時，encrypedpwd使用者必須是密文，
另一種方式是先addauth digest:usrname:password 先把授權資訊加入上下文，這裡password用的是明文，然後再setAcl /pathauth:username:password:crdwa
所以如果在cli控制檯測試，強烈建議用第二種方式，否則象上圖中的方式用錯了方式，pwd-b1在zk中被認為是密文，要解密出來幾乎不可能，所以設定後，相當於這個節點就廢了，因為你不知道密碼，要操作該節點時，提供不了正確的認證資訊)
紅線4：還是剛才的理由，因為/a/b為world:anyone:cdrwa，沒有限制，所以刪除其下的子節點不受阻擋。
從上圖可以看出，無法get父節點的內容，但是可以get子節點的內容，再次說明父、子節點的許可權沒直接關係，但是做delete時，上面的例子卻遇到了麻煩：
想刪除/a/b時，由於父節點/a的ACL列表裡，只有ra許可權，沒有d許可權，所以無法刪除子節點。想刪除/a時，發現下面還有子節點b，節點非空無法刪除，所以這個示例就無解了（因為根據前面的操作，密碼也還原不出來，也就無法修改ACL屬性），而根節點/也無法刪除，解決辦法，只能到data目錄裡清空所有資料，再重啟zk，但是這樣就相當於所有資料全扔了，所以在設計ACL時，對於delete許可權，要謹慎規劃，在測試zk叢集上做好測試，再轉到生產環境操作。
最後給一些許可權組合的測試結果：
要修改某個節點的ACL屬性，必須具有read、admin二種許可權
要刪除某個節點下的子節點，必須具有對父節點的read許可權，以及父節點的delete許可權
ACL 使用場景
- 開發、測試環境分離，開發者無權操作測試庫節點
- 生產環境控制指定 ip 的服務可以訪問相關節點，防止混亂
java 實現：
注意zk 連線之後，做了一個許可權認證，這個認證可以保證後續所有操作都是OK的
java許可權擴充套件
儘管ZooKeeper已經為我們提供了上述的四種許可權模式，同時也提供給我們能夠自定義自己許可權的方式——實現介面
org.apache.zookeeper.server.auth.AuthenticationProvider
- 啟動引數配置
在ZooKeeper啟動引數中配置類似於如下的系統屬性
-Dzookeeper.authProvider.1=com.zkbook.CustomAuthenticationProvider
- 配置檔案配置
在zoo.cfg配置檔案中配置類似於如下的配置項
authProvider.1=com.zkbook.CustomAuthenticationProvider