ZooKeeper的數據模型提供了ACL機制來控制訪問znode。 在創建znode時，ACL將確定你可以在znode上執行的各種操作的權限。 ZooKeeper ACL模型與Unix / Linux文件許可類似，允許或阻止通過設置/取消權限位在znode上執行操作。 但是，ZooKeeper節點并不具有Unix/Linux文件系統中所有權的概念。 ACL是基于客戶端和ZooKeeper服務的認證機制來確定的。

ZooKeeper基于ACL提供了以下內置認證機制：

• World：這代表任何人都可以連接到ZooKeeper服務
• Auth：這表示任何經過身份驗證的用戶，但不使用任何ID
• Digest：這代表了用戶名和密碼的認證方式
• IP address：這表示使用客戶端的IP地址進行身份驗證

除了前面列出的認證方案外，ZooKeeper還支持可插入的認證機制，如果需要，可以集成第三方認證方案。 ZooKeeper中的任何認證方案都包含以下兩個主要認證操作：

• 首先，ZooKeeper中的認證框架對客戶端進行認證。 客戶端驗證發生在客戶端通過客戶端信息驗證連接到ZooKeeper服務時。

• 其次，認證框架查找ACL中與客戶端對應的表項。 ACL條目是由<IDs，Permissions>組成的對，其中ID是標識客戶端的字符串。

有關znode ACL的重要的一點是，與特定znode關聯的ACL不會傳播給其子節點。 客戶使用ZooKeeper進行認證是可選的; 如果與znode相關的ACL需要客戶端進行身份驗證，則必須使用前面提到的身份驗證機制進行身份驗證。 ACL是身份和一組權限組合的認證機制。

ZooKeeper的ACL支持以下權限：

操作ACL 權限

CREATE	創建一個子節點
READ	獲取子節點列表和與znode相關的數據
WRITE	將數據設置（寫入）到znode
DELETE	刪除一個孩子子節點
ADMIN	設置ACL（權限）

任何連接到ZooKeeper服務的客戶端都有權檢查是否存在znode。 這個exist操作是不需要權限的，它允許檢索一個znode的stat結構。

ZooKeeper中有許多預定義的ACL。 這些由ZooKeeper ACL定義的ID如下表所示：

ACL權限

ANYONE_ID_UNSAFE	這個ID代表任何人
AUTH_IDS	這是用來設置ACL，用被認證的客戶端的ID代替
OPEN_ACL_UNSAFE	這表示完全打開的ACL，并授予除ADMIN權限之外的所有權限
CREATOR_ALL_ACL	該ACL將所有權限授予znode的創建者
READ_ACL_UNSAFE	這個ACL賦予所有人讀取的能力

總結

以上是生活随笔為你收集整理的6. ZooKeeper访问控制列表的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。