今天小編分享一篇關于Zookeeper權限控制&身份驗證的內容，內容主要是對官方文檔的翻譯，在翻譯過程中加入了小編自己的理解，并使用比較容易理解的方式進行表述和修飾，希望能幫各位開發小伙伴更新容易理解相關的內容；小編之前也分享過Zookeeper相關的文檔，可參考如下鏈接：

Zookeeper概覽-官方文檔翻譯
Zookeeper開發者指南——Zookeeper數據模型
Zookeeper開發指南——Zookeeper會話
Zookeeper開發指南——Zookeeper監聽

Zookeeper使用ACLs進行訪問控制（ZooKeeper access control using ACLs）

Zookeeper使用ACLs控制對節點的訪問；ACL的實現與 UNIX 文件訪問權限非常相似：它使用權限位來允許/禁止對節點的各種操作以及這些權限位適用的范圍。但與標準 UNIX 權限不同，Zookeeper 節點不受“用戶（文件所有者）”、“組”和“其他”三個標準范圍的限制。Zookeeper 沒有znode 所有者的概念。相反，ACL是指定一組 id 和與這些 id 關聯的權限。

另外請注意，ACL僅適用于特定的znode，特別是不適用于子節點。例如：如果 /App 只能被 ip:172.16.16.1 讀取，并且 /app/status的權限范圍是所有人，那么任何人都可以讀取 /app/status； ACL不是遞歸的。

ZooKeeper 支持插拔式的身份驗證方案。使用scheme:expression格式來指定ID列表，其中 scheme 是ID對應的身份驗證方案，有效的expression集合由scheme定義。例如，ip:172.16.16.1 是使用ip方案來指定的ID, 其中主機地址為 172.16.16.1，表示該IP地址的主機有權限，而 digest:bob:password 表示了用戶名稱為bob的digest方案對應的ID。

當客戶端連接到 ZooKeeper 并對其自身進行身份驗證時，ZooKeeper 會將與客戶端對應的所有 id 與客戶端連接相關聯。當客戶端嘗試訪問節點時，這些 id 會根據 znode 的 ACL 進行檢查。 ACL 由成對的 (scheme:expression, perms) 組成。表達式的格式會根據方案不同而有所不同。例如， (ip:19.22.0.0/16, READ) 將 READ 權限授予 IP 地址以 19.22 開頭的任何客戶端。

ACL權限

Zookeeper支持以下的權限:

CREATE: 開發者可以創建一個子節點
READ: 開發者可以獲取節點的數據以及子節點列表
WRITE: 開發者可以為節點設置數據
DELETE: 開發者可刪除一個子節點
ADMIN: 開發者擁有管理員角色，可以設置權限

CREATE 和 DELETE 權限已從 WRITE 權限中分離出來，以實現更精細的訪問控制。 CREATE 和 DELETE 的場景如下：

希望 A 能夠在 ZooKeeper 節點上進行設置，但不能CREATE 或DELETE 子節點。

CREATE：客戶端通過在父目錄中創建 ZooKeeper 節點來創建請求。開發者希望所有客戶端都可以添加節點，但只有請求處理器可以刪除。

此外，由于 ZooKeeper 沒有文件所有者的概念，因此就有了ADMIN 權限。在某種意義上，ADMIN 權限將實體指定為所有者。 ZooKeeper 不支持 LOOKUP 權限（對目錄執行權限位以允許開發者在無法列出目錄的情況下進行 LOOKUP）。每個人都隱含地擁有 LOOKUP 權限。這允許開發者統計一個節點，但僅此而已，沒有其他用途。（問題是，如果你想在一個不存在的節點上調用 zoo_exists()，則沒有權限校驗）

ADMIN 權限依照 ACL規定，也有特殊的用法：為了檢索 znode的 ACL，用戶必須具有 READ 或 ADMIN 權限，但如果沒有 ADMIN 權限，DIGEST哈希值將被屏蔽掉。

內置 ACL 方案Builtin ACL Schemes

Zookeeper包含以下內置方案：ZooKeeeper has the following built in schemes:

world ：有一個 id：anyone，代表任何人
auth ：auth是一種特殊方案，它忽略任何提供的表達式，而是使用當前用戶、憑據和方案。在持久化 ACL 時，ZooKeeper 服務器會忽略提供的任何表達式（無論是使用 SASL 身份驗證的用戶還是使用 DIGEST 身份驗證的 user:password）。但是，仍必須在 ACL 中提供表達式，因為 ACL 必須匹配格式 scheme:expression:perms。提供此方案是為了方便，常見的用法是用戶創建 znode ，然后將對該 znode 的訪問限制為僅該用戶。如果沒有經過身份驗證的用戶，使用 auth 方案設置 ACL 將會失敗。
digest：DIGEST使用username:passowrd字符串生成MD5 哈希值，然后使用該哈希值作為ACL的ID身份。通過以明文形式發送username:password來完成身份驗證。在 ACL 中使用時，表達式將是 username:password(密碼是SHA1編碼的base64) digest。
ip 方案使用客戶端主機IP 作為ACL的ID身份。ACL 表達式的格式為 addr/bits，其中 addr 的最高有效位與客戶端主機 IP 的最高有效位相匹配。
x509：x509 使用客戶端X500 主體作為ACL ID 身份。 ACL 表達式是客戶端的明確的 X500 主體名稱。使用安全端口時，客戶端會自動進行身份驗證，并設置 x509 方案的身份驗證信息。

Zookeeper C語言客戶端API

The following constants are provided by the ZooKeeper C library:

以下常量是由Zookeeper C語言客戶端庫提供：

const int ZOO_PERM_READ; //能讀取節點數據以及節點的子節點
const int ZOO_PERM_WRITE;// 可以設置節點數據
const int ZOO_PERM_CREATE; //可以創建子節點
const int ZOO_PERM_DELETE;// 可以刪除子節點
const int ZOO_PERM_ADMIN; //能夠執行set_acl()
const int ZOO_PERM_ALL;// 上述全部標志位的“或”運算的結果

Zookeeper可插拔式的身份驗證Pluggable ZooKeeper authentication

ZooKeeper 運行在各種不同的環境中，具有各種不同的身份驗證方案，因此它具有完全可插拔的身份驗證框架。即使是內置的身份驗證方案也使用可插拔的身份驗證框架。

要了解身份驗證框架的工作原理，首先必須了解兩個主要的身份驗證操作。框架首先必須對客戶端進行身份驗證。這通常在客戶端連接到服務器后立即完成，包括驗證從客戶端發送的或收集的關于客戶端的信息并將其與連接相關聯。框架處理的第二個操作是在 ACL 中查找與客戶端對應的條目。 ACL 條目是 <idspec, permissions> 對。 idspec 可以是與連接關聯的身份驗證信息匹配的簡單字符串，也可以是根據該信息進行計算的表達式。具體取決于身份驗證插件的實現。這是身份驗證插件必須實現的接口：

public interface AuthenticationProvider {
   		String getScheme();
      KeeperException.Code handleAuthentication(ServerCnxn cnxn, byte authData[]);
      boolean isValid(String id);
      boolean matches(String id, String aclExpr);
      boolean isAuthenticated();
  }

第一個方法getScheme返回標識插件的字符串。因為支持多種身份驗證方法，所以身份驗證憑證或idspec總是以scheme:作為前綴。ZooKeeper服務器使用認證插件返回的方案來確定該方案適用于哪些id。

當客戶端給服務端發送與連接關聯的身份驗證信息時，調用handleAuthentication方法。客戶端指定信息對應的方案，然后ZooKeeper服務器將身份認證信息傳遞給認證插件，插件的getScheme方法返回的方案與客戶端傳遞的方案匹配。如果handleAuthentication的實現者確定信息是錯誤的，它通常會返回一個錯誤，否則使用cnxn.getAuthInfo().add(new Id(getScheme(), data))將身份驗證信息與連接關聯起來。

身份驗證插件涉及到ACL的設置和使用。當為znode設置ACL時，ZooKeeper服務器會將數據項中的id部分傳遞給isValid(String id)方法。由插件來驗證id是否具有正確的格式和結構。例如，ip:172.16.0.0/16是合法的id, 但是ip:host.com不是合法的id。如果新的ACL包含一個“auth”數據項，則使用isAuthenticated來查看是否應該將與連接相關聯的方案的認證信息添加到ACL中。有些方案不應該包含在auth中。例如，如果指定了auth，則不應該將客戶端的IP地址視為應該添加到ACL中的id。

Zookeeper檢查ACL時會調用matches(String id, String aclExpr)。檢查時需要將客戶端的認證信息與相應的ACL數據項進行匹配。為了找到適用于客戶端的數據項，ZooKeeper服務器將查找每個數據項的方案，如果客戶端有該方案的認證信息，則 matches(String id, String aclExpr) 將被調用，其中id為由handleAuthentication方法添加到連接中的身份驗證信息中的id，aclExpr為ACL數據項中的ID。身份驗證插件使用自己的邏輯和匹配方案來確定id是否包含在aclExpr中

有兩個內置的身份驗證插件：ip 和 digest。可以使用系統屬性添加其他插件。在啟動時，ZooKeeper 服務器將查找以“zookeeper.authProvider”開頭的系統屬性。并將這些屬性的值作為身份驗證插件的類名。可以使用
-Dzookeeeper.authProvider.X=com.f.MyAuth 或在服務器配置文件中添加如下配置信息來設置這些屬性：

authProvider.1=com.f.MyAuth

authProvider.2=com.f.MyAuth2

應注意確保屬性上的后綴是唯一的。如果存在重復，則只會使用一個，例如
-Dzookeeeper.authProvider.X=com.f.MyAuth -Dzookeeper.authProvider.X=com.f.MyAuth2。

此外，所有服務器都必須定義相同的插件，否則使用插件提供的身份驗證方案的客戶端將無法連接到某些服務器。

3.6.0 中新增的內容：可插拔身份驗證可以使用的另一種抽象。它提供了額外的參數。

public abstract class ServerAuthenticationProvider implements AuthenticationProvider {
   public abstract KeeperException.Code handleAuthentication(ServerObjs serverObjs, byte authData[]);
	public abstract boolean matches(ServerObjs serverObjs, MatchValues matchValues);
}

如果開發者擴展了
ServerAuthenticationProvider，而不是實現 AuthenticationProvider。則 handleAuthentication() 和 matches() 方法將接收到額外的參數（ ServerObjs 和 MatchValues）