Athenz 是 Yahoo 開源的權限系統 [1]，基於 X.509 Certificate 的架構來提供權限認證的功能。運作上跟 AWS IAM 蠻類似的，是以 Role 為基礎，透過指定某個 Role 對某個 Resource 允許或拒絕某些 Action 來達成授權行為。
Athenz 的授權流程可以區分為集中式與分散式兩種，可以參考 Github 的說明 [2]，這裡引用了 [2] 的流程圖並且簡單描述一下。
Centralized Access Control (Control Plane)
集中式的授權就是比較單純地讓服務直接詢問 ZMS，得到 true/false 的回覆來確認是否具有權限。換言之，就是確認是否有權限的永遠都是由 ZMS 擔任，其他人想知道是否有權限，都要去問 ZMS。流程上這個模式比較簡單，但是可以想像因為每次要確認權限時，都得發 request 給 ZMS 做查詢，因此效率較差（latency 較高），而且也可能會有單點故障或者流量等的議題存在。
集中式的授權流程，截自 [2]
上圖中右下角的 Service A 是客戶端服務，左下角的 Service B 是服務端。圖中的 (1) ~ (8) 都是一般 X.509 的步驟，讓 CA 能夠認識 Service A。(9) ~ (11) 是 Service A 存取 Service B，此時 Service B 會直接發 request 去 ZMS 確認 Service A 是否擁有權限可以對 B.resource 執行 B.action 的操作。
Decentralized Access Control (Data Plane)
在分散式的授權中，客戶端會先取得一個 ZToken，並且直到這個 ZToken 失效前，存取其他服務時都會附上這個 ZToken。而服務端則是透過位於本地的 ZPE（Athenz Policy Engine）來驗證 ZToken。流程如下圖所示。
分散式的授權流程，截自 [2]
上圖中，右下角的客戶端服務 Service A 的前置步驟 (1) ~ (8) 跟集中式的授權流程是一樣的，都是標準的 X.509 的程序。到了步驟 (9) 時，Service A 會向 ZTS 要求一個 ZToken，並且接著以這個 ZToken 發送 request 給 Service B。Service B 會向本地的 ZPE 確認授權，其中 ZPE 會依照它自己在本地留存的 Policy 資料來決定應該要回覆允許還是拒絕。
至於 ZPE 為什麼能夠神奇地做好本地驗證，其實也沒什麼神奇的地方，就是有個 ZPU（Athenz Policy Engine Updater）定期去 ZTS 上同步 Policy 下來。所以整體來說，去 ZTS 詢問的動作依然是存在的，只不過變成交由 ZPU 非同步地定期進行。
沒有留言:
張貼留言