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

Zookeeper概覽-官方文檔翻譯
Zookeeper開(kāi)發(fā)者指南——Zookeeper數(shù)據(jù)模型
Zookeeper開(kāi)發(fā)指南——Zookeeper會(huì)話(huà)
Zookeeper開(kāi)發(fā)指南——Zookeeper監(jiān)聽(tīng)

Zookeeper使用ACLs進(jìn)行訪問(wèn)控制（ZooKeeper access control using ACLs）

Zookeeper使用ACLs控制對(duì)節(jié)點(diǎn)的訪問(wèn)；ACL的實(shí)現(xiàn)與 UNIX 文件訪問(wèn)權(quán)限非常相似：它使用權(quán)限位來(lái)允許/禁止對(duì)節(jié)點(diǎn)的各種操作以及這些權(quán)限位適用的范圍。但與標(biāo)準(zhǔn) UNIX 權(quán)限不同，Zookeeper 節(jié)點(diǎn)不受“用戶(hù)（文件所有者）”、“組”和“其他”三個(gè)標(biāo)準(zhǔn)范圍的限制。Zookeeper 沒(méi)有znode 所有者的概念。相反，ACL是指定一組 id 和與這些 id 關(guān)聯(lián)的權(quán)限。

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

ZooKeeper 支持插拔式的身份驗(yàn)證方案。使用scheme:expression格式來(lái)指定ID列表，其中 scheme 是ID對(duì)應(yīng)的身份驗(yàn)證方案，有效的expression集合由scheme定義。例如，ip:172.16.16.1 是使用ip方案來(lái)指定的ID, 其中主機(jī)地址為 172.16.16.1，表示該IP地址的主機(jī)有權(quán)限，而 digest:bob:password 表示了用戶(hù)名稱(chēng)為bob的digest方案對(duì)應(yīng)的ID。

當(dāng)客戶(hù)端連接到 ZooKeeper 并對(duì)其自身進(jìn)行身份驗(yàn)證時(shí)，ZooKeeper 會(huì)將與客戶(hù)端對(duì)應(yīng)的所有 id 與客戶(hù)端連接相關(guān)聯(lián)。當(dāng)客戶(hù)端嘗試訪問(wèn)節(jié)點(diǎn)時(shí)，這些 id 會(huì)根據(jù) znode 的 ACL 進(jìn)行檢查。 ACL 由成對(duì)的 (scheme:expression, perms) 組成。表達(dá)式的格式會(huì)根據(jù)方案不同而有所不同。例如， (ip:19.22.0.0/16, READ) 將 READ 權(quán)限授予 IP 地址以 19.22 開(kāi)頭的任何客戶(hù)端。

ACL權(quán)限

Zookeeper支持以下的權(quán)限:

CREATE: 開(kāi)發(fā)者可以創(chuàng)建一個(gè)子節(jié)點(diǎn)
READ: 開(kāi)發(fā)者可以獲取節(jié)點(diǎn)的數(shù)據(jù)以及子節(jié)點(diǎn)列表
WRITE: 開(kāi)發(fā)者可以為節(jié)點(diǎn)設(shè)置數(shù)據(jù)
DELETE: 開(kāi)發(fā)者可刪除一個(gè)子節(jié)點(diǎn)
ADMIN: 開(kāi)發(fā)者擁有管理員角色，可以設(shè)置權(quán)限

CREATE 和 DELETE 權(quán)限已從 WRITE 權(quán)限中分離出來(lái)，以實(shí)現(xiàn)更精細(xì)的訪問(wèn)控制。 CREATE 和 DELETE 的場(chǎng)景如下：

希望 A 能夠在 ZooKeeper 節(jié)點(diǎn)上進(jìn)行設(shè)置，但不能CREATE 或DELETE 子節(jié)點(diǎn)。

CREATE：客戶(hù)端通過(guò)在父目錄中創(chuàng)建 ZooKeeper 節(jié)點(diǎn)來(lái)創(chuàng)建請(qǐng)求。開(kāi)發(fā)者希望所有客戶(hù)端都可以添加節(jié)點(diǎn)，但只有請(qǐng)求處理器可以刪除。

此外，由于 ZooKeeper 沒(méi)有文件所有者的概念，因此就有了ADMIN 權(quán)限。在某種意義上，ADMIN 權(quán)限將實(shí)體指定為所有者。 ZooKeeper 不支持 LOOKUP 權(quán)限（對(duì)目錄執(zhí)行權(quán)限位以允許開(kāi)發(fā)者在無(wú)法列出目錄的情況下進(jìn)行 LOOKUP）。每個(gè)人都隱含地?fù)碛?LOOKUP 權(quán)限。這允許開(kāi)發(fā)者統(tǒng)計(jì)一個(gè)節(jié)點(diǎn)，但僅此而已，沒(méi)有其他用途。（問(wèn)題是，如果你想在一個(gè)不存在的節(jié)點(diǎn)上調(diào)用 zoo_exists()，則沒(méi)有權(quán)限校驗(yàn)）

ADMIN 權(quán)限依照 ACL規(guī)定，也有特殊的用法：為了檢索 znode的 ACL，用戶(hù)必須具有 READ 或 ADMIN 權(quán)限，但如果沒(méi)有 ADMIN 權(quán)限，DIGEST哈希值將被屏蔽掉。

內(nèi)置 ACL 方案Builtin ACL Schemes

Zookeeper包含以下內(nèi)置方案：ZooKeeeper has the following built in schemes:

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

Zookeeper C語(yǔ)言客戶(hù)端API

The following constants are provided by the ZooKeeper C library:

以下常量是由Zookeeper C語(yǔ)言客戶(hù)端庫(kù)提供：

const int ZOO_PERM_READ; //能讀取節(jié)點(diǎn)數(shù)據(jù)以及節(jié)點(diǎn)的子節(jié)點(diǎn)
const int ZOO_PERM_WRITE;// 可以設(shè)置節(jié)點(diǎn)數(shù)據(jù)
const int ZOO_PERM_CREATE; //可以創(chuàng)建子節(jié)點(diǎn)
const int ZOO_PERM_DELETE;// 可以刪除子節(jié)點(diǎn)
const int ZOO_PERM_ADMIN; //能夠執(zhí)行set_acl()
const int ZOO_PERM_ALL;// 上述全部標(biāo)志位的“或”運(yùn)算的結(jié)果

Zookeeper可插拔式的身份驗(yàn)證Pluggable ZooKeeper authentication

ZooKeeper 運(yùn)行在各種不同的環(huán)境中，具有各種不同的身份驗(yàn)證方案，因此它具有完全可插拔的身份驗(yàn)證框架。即使是內(nèi)置的身份驗(yàn)證方案也使用可插拔的身份驗(yàn)證框架。

要了解身份驗(yàn)證框架的工作原理，首先必須了解兩個(gè)主要的身份驗(yàn)證操作?？蚣苁紫缺仨殞?duì)客戶(hù)端進(jìn)行身份驗(yàn)證。這通常在客戶(hù)端連接到服務(wù)器后立即完成，包括驗(yàn)證從客戶(hù)端發(fā)送的或收集的關(guān)于客戶(hù)端的信息并將其與連接相關(guān)聯(lián)?？蚣芴幚淼牡诙€(gè)操作是在 ACL 中查找與客戶(hù)端對(duì)應(yīng)的條目。 ACL 條目是 <idspec, permissions> 對(duì)。 idspec 可以是與連接關(guān)聯(lián)的身份驗(yàn)證信息匹配的簡(jiǎn)單字符串，也可以是根據(jù)該信息進(jìn)行計(jì)算的表達(dá)式。具體取決于身份驗(yàn)證插件的實(shí)現(xiàn)。這是身份驗(yàn)證插件必須實(shí)現(xiàn)的接口：

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

第一個(gè)方法getScheme返回標(biāo)識(shí)插件的字符串。因?yàn)橹С侄喾N身份驗(yàn)證方法，所以身份驗(yàn)證憑證或idspec總是以scheme:作為前綴。ZooKeeper服務(wù)器使用認(rèn)證插件返回的方案來(lái)確定該方案適用于哪些id。

當(dāng)客戶(hù)端給服務(wù)端發(fā)送與連接關(guān)聯(lián)的身份驗(yàn)證信息時(shí)，調(diào)用handleAuthentication方法。客戶(hù)端指定信息對(duì)應(yīng)的方案，然后ZooKeeper服務(wù)器將身份認(rèn)證信息傳遞給認(rèn)證插件，插件的getScheme方法返回的方案與客戶(hù)端傳遞的方案匹配。如果handleAuthentication的實(shí)現(xiàn)者確定信息是錯(cuò)誤的，它通常會(huì)返回一個(gè)錯(cuò)誤，否則使用cnxn.getAuthInfo().add(new Id(getScheme(), data))將身份驗(yàn)證信息與連接關(guān)聯(lián)起來(lái)。

身份驗(yàn)證插件涉及到ACL的設(shè)置和使用。當(dāng)為znode設(shè)置ACL時(shí)，ZooKeeper服務(wù)器會(huì)將數(shù)據(jù)項(xiàng)中的id部分傳遞給isValid(String id)方法。由插件來(lái)驗(yàn)證id是否具有正確的格式和結(jié)構(gòu)。例如，ip:172.16.0.0/16是合法的id, 但是ip:host.com不是合法的id。如果新的ACL包含一個(gè)“auth”數(shù)據(jù)項(xiàng)，則使用isAuthenticated來(lái)查看是否應(yīng)該將與連接相關(guān)聯(lián)的方案的認(rèn)證信息添加到ACL中。有些方案不應(yīng)該包含在auth中。例如，如果指定了auth，則不應(yīng)該將客戶(hù)端的IP地址視為應(yīng)該添加到ACL中的id。

Zookeeper檢查ACL時(shí)會(huì)調(diào)用matches(String id, String aclExpr)。檢查時(shí)需要將客戶(hù)端的認(rèn)證信息與相應(yīng)的ACL數(shù)據(jù)項(xiàng)進(jìn)行匹配。為了找到適用于客戶(hù)端的數(shù)據(jù)項(xiàng)，ZooKeeper服務(wù)器將查找每個(gè)數(shù)據(jù)項(xiàng)的方案，如果客戶(hù)端有該方案的認(rèn)證信息，則 matches(String id, String aclExpr) 將被調(diào)用，其中id為由handleAuthentication方法添加到連接中的身份驗(yàn)證信息中的id，aclExpr為ACL數(shù)據(jù)項(xiàng)中的ID。身份驗(yàn)證插件使用自己的邏輯和匹配方案來(lái)確定id是否包含在aclExpr中

有兩個(gè)內(nèi)置的身份驗(yàn)證插件：ip 和 digest。可以使用系統(tǒng)屬性添加其他插件。在啟動(dòng)時(shí)，ZooKeeper 服務(wù)器將查找以“zookeeper.authProvider”開(kāi)頭的系統(tǒng)屬性。并將這些屬性的值作為身份驗(yàn)證插件的類(lèi)名。可以使用
-Dzookeeeper.authProvider.X=com.f.MyAuth 或在服務(wù)器配置文件中添加如下配置信息來(lái)設(shè)置這些屬性：

authProvider.1=com.f.MyAuth

authProvider.2=com.f.MyAuth2

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

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

3.6.0 中新增的內(nèi)容：可插拔身份驗(yàn)證可以使用的另一種抽象。它提供了額外的參數(shù)。

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

如果開(kāi)發(fā)者擴(kuò)展了
ServerAuthenticationProvider，而不是實(shí)現(xiàn) AuthenticationProvider。則 handleAuthentication() 和 matches() 方法將接收到額外的參數(shù)（ ServerObjs 和 MatchValues）