ZooKeeper程式設計指南（四）

訪問控制

zk使用acls（access control list）來控制對節點的訪問。acl實現類似於unix的檔案許可權控制：使用許可權位來允許/禁止對節點的各種操作和一些位的作用範圍。不像unix許可權，zk節點不受限於3個標準的範圍 -- 使用者（owner），組，其它（world）。zk沒有節點擁有者的概念。相反acl指定id集合和id集合對應的許可權。

zk支援可插拔的認證方案。ids（識別符號，標識客戶端的id，id的組合）使用這種形式scheme:id，scheme是id對應的認證方案。例如

ip:172.16.16.1就是乙個id，對應乙個ip位址為

172.16.16.1的主機。

當客戶端連線到zk認證自己時，zk把所有的客戶端對應的ids（這些ids應該是zk伺服器根據客戶端的相關屬性生成的，比如ip）（也就代表當前客戶端的許可權）關聯到當前連線上。當訪問節點時，ids和節點的訪問控制列表對比。訪問控制列表（表示節點許可權）由成對的(scheme:expression, perms)組成。表示式（expression）的格式特定於scheme（和scheme對應）。例如，(ip:19.22.0.0/16, read) 表示：任何ip位址以19.22開頭的客戶端都有讀許可權。

acl許可權

zk支援下面的許可權

1、create 建立子節點

2、read 獲取節點data和節點的子節點

3、write 設定節點data

4、delete 刪除子節點

5、設定許可權

create和delete許可權從write許可權中脫離是為了更細粒度的許可權控制。

create和delete的場景如下：

希望a能夠設定節點的資料，但不能夠建立或刪除該節點子節點。

有admin許可權是因為zk沒有檔案所有者的概念。在某種意義上，admin許可權制定某個實體（entity，個體）為擁有者。zk不支援lookup許可權（目錄的查詢許可權位支援lookup操作，即使沒有列出目錄的許可權）。所有的使用者隱含都有lookup的許可權，這允許使用者獲取節點狀態，僅僅只有這些（有乙個問題是，在不存在的節點上執行

zoo_exists()，這種操作不允許

）。

內建方案 zk有下面的內建方案

1、world，有唯一的id，「anyone」，表示任何使用者（客戶端）

2、auth，不適用任何id，表示任何授權的使用者

3、digest，ca，感覺這塊的官方文件說的不清楚。

4、ip，使用客戶端ip作為id，acl的表示式形式是

addr/bits，addr的最高有效位bits個和客戶端ip的最高有效位bits個匹配。

可擴充的認證

zk使用不同的認證方案，執行在不同的環境中。因此他又乙個完全可擴充的認證框架。即使內部的認證方案，也使用了可擴充的認證框架。

要理解認證框架如何工作，首先必須理解兩個主要的認證操作。框架首先認證客戶端。當客戶端連線到伺服器時就開始認證，包括客戶端傳送的資訊和從客戶端收集的資訊，並且關聯到連線。框架執行的第二個操作是找到acl中和客戶端對應的乙個條目。acl條目是的形式。idspec可能是簡單的字串，直接可以和連線裡面的認證資訊對比，也可能是乙個表示式，和連線裡的資訊進行計算。認證外掛程式的實現負責匹配。

下面是認證外掛程式必須實現的介面：

public inte***ce authenticationprovider

getscheme()返回認證外掛程式的識別符號。因為我們支援多種認證方法。認證的憑據或idspec必須追加scheme的字首。zk伺服器使用認證外掛程式返回的方案來確定方案應用的ids。

當客戶端傳送認證資訊，handleauthentication ()被呼叫。客戶端指定資訊對應的方案。伺服器傳遞資訊到認證外掛程式（getscheme()返回的和客戶端傳遞的相同）。

handleauthentication ()方法會在確定資訊錯誤時返回error，否則它會關聯資訊到連線（使用

cnxn.getauthinfo().add(new id(getscheme(), data))

）。

ZooKeeper程式設計指南（四）

ZooKeeper 程式設計指南

Spark Streaming程式設計指南（四）

ZooKeeper安裝指南

ZooKeeper程式設計指南（四）

ZooKeeper 程式設計指南

Spark Streaming程式設計指南（四）

ZooKeeper安裝指南

相關推薦