DAOS 分佈式異步對象存儲｜安全模型

時間 2021-04-04

標籤 html git github 安全網絡數據結構 dom 分佈式工具 this 欄目系統架構简体版

原文原文鏈接

DAOS 使用了一個靈活的安全模型，將身份驗證和受權分離開來。它的設計令其對 I/O 的影響被降到最小。html

DAOS 對用於 I/O 傳輸的網絡結構沒有提供任何傳輸安全性保障。在部署 DAOS 時，管理員負責特定網絡結構的安全配置。對於以太網 RDMA，建議啓用 IPsec。有關更多信息，請參閱 RDMA protocol spec (RFC 5040) 。git

DAOS 從兩個方面實現本身的安全層：github

在用戶級別，客戶端只能讀取和修改被授予訪問權限的 Pool 和 Container。
在系統和管理級別，只有通過受權的組件才能訪問 DAOS 管理網絡。

驗證

有不一樣的身份驗證方法，這取決於調用者是訪問客戶端資源仍是 DAOS 管理網絡。安全

客戶端庫

客戶端庫 libdaos 是不受信任的組件。使用客戶端庫的 DAOS 用戶級命令也是不受信任的組件。網絡

受信任的 DAOS 代理進程 daos_agent 在每一個客戶端節點上運行，並對用戶進程進行身份驗證。數據結構

DAOS 安全模型的設計支持客戶端進程的不一樣身份驗證方法。目前，咱們只支持 AUTH_SYS 身份驗證。dom

DAOS 管理網絡

每一個受信任的 DAOS 組件（daos_server、daos_agent 和 dmg 管理工具）都經過爲該組件生成的證書進行身份驗證。這些組件經過相互認證的 TLS 在 DAOS 管理網絡上相互標識。分佈式

受權

資源的客戶端受權由資源的訪問控制列表 (Access Control List, ACL) 控制。管理網絡上的受權是經過配置 DAOS 系統時生成的 certificates 上的設置來實現的。工具

組件證書

對 DAOS management RPCs 的訪問是經過設置每一個管理組件證書中的 CommonName (CN) 進行控制的。給定的 management RPC 只能由與正確證書鏈接的組件調用。this

訪問控制列表

客戶端對 Pool 和 Container 等資源的訪問由 DAOS 訪問控制列表 (ACL) 控制。這些 ACL 部分來自 NFSv4 ACL，而且適應分佈式系統的特殊需求。

客戶端支持對請求對資源的進行只讀或讀寫訪問。若是資源的 ACL 沒有給它們的請求授予訪問級別，客戶端將沒法鏈接資源。

鏈接時，它們對該資源的句柄將被授予特定操做的權限。句柄的權限在其存在期間保持，相似於 POSIX 系統中的打開文件描述符，此時沒法註銷句柄。

訪問控制項

在 DAOS 工具的輸入和輸出中，訪問控制項 (Access Control Entry, ACE) 是用冒號分隔的字符串定義的，格式以下：

TYPE:FLAGS:PRINCIPAL:PERMISSIONS

全部字段都區分大小寫。

TYPE
- 必須字段
- ACE 的類型。目前只支持一種類型的 ACE。
  - A (Allow)：容許經過給定權限訪問指定主體。
FLAGS
- 可選字段。
- 提供有關如何解釋 ACE 的附加信息。
  - G (Group)：主體應被解釋爲一個羣體。
PRINCIPAL
- 主體（也稱爲標識）的具體格式爲 name@domain。若是名稱是本地域的 UNIX 用戶/組，則應省略該域。目前，這是 DAOS 支持的惟一方式。
- 有三個特殊的主體，OWNER@、GROUP@ 和 EVERYONE@，它們與傳統 POSIX 權限位中的 User、Group 和Other 對齊。當以 ACE 字符串格式提供它們時，它們的拼寫必須與此處所寫的徹底一致：大寫，不附加域。GROUP@ 項還必須有 G (Group) 標誌。
PERMISSIONS
- 資源 ACE 中的權限容許特定類型的用戶訪問資源。
- ACE 權限字段中權限位（字符）的順序不重要。
- 包含不適用於給定資源的權限的 ACE 被視爲無效。
- 要容許用戶/組鏈接到資源，主體的權限必須至少包括某種形式的讀取訪問（例如 read 或 get-prop）。具備只寫權限的用戶在請求對資源的 RW 訪問時將被拒絕。

Permission	Pool Meaning	Container Meaning
r (Read)	Alias for 't'	Read container data and attributes
w (Write)	Alias for 'c' + 'd'	Write container data and attributes
c (Create)	Create containers	N/A
d (Delete)	Delete any container	Delete this container
t (Get-Prop)	Connect/query	Get container properties
T (Set-Prop)	N/A	Set/Change container properties
a (Get-ACL)	N/A	Get container ACL
A (Set-ACL)	N/A	Set/Change container ACL
o (Set-Owner)	N/A	Set/Change container's owner user and group

拒絕訪問
- 目前，只支持設置「容許」訪問控制項。
- 可是，能夠經過爲沒有權限的特定用戶建立容許條目來拒絕對其的訪問。這與刪除用戶的 ACE 有本質不一樣，後者容許 ACL 中的其餘 ACE 肯定其訪問權限。
- 因爲組權限的強制方式，沒法以這種方式拒絕對特定組的訪問。
ACE 示例
- A::daos_user@:rw
  - 容許名爲 daos_user 的 UNIX 用戶具備讀寫訪問權限。
- A::project_users@:tc
  - 容許 UNIX 組 project_users 中的任何人訪問 Pool 的內容並建立 Container。
- A::OWNER@:rwdtTaAo
  - 容許擁有 Container 的 UNIX 用戶具備徹底控制權。
- A:G:GROUP@:rwdtT
  - 容許擁有 Container 的 UNIX 組讀寫數據、刪除 Container 和操做 Container 屬性。
- A::EVERYONE@:r
  - 容許其餘規則未涵蓋的任何用戶具備只讀訪問權限。
- A::daos_user@:
  - 拒絕名爲 daos_user 的 UNIX 用戶對資源的任何訪問。

強制執行

訪問控制項 (ACE) 將按如下順序執行：

全部者用戶 (Owner-User)
命名用戶 (Named users)
全部者組和命名組 (Owner-Group and named groups)
全部人 (Everyone)

通常來講，強制執行將第一個匹配，並忽略較低優先級的條目。

若是用戶是資源的全部者，而且存在 OWNER@ 項，則僅接受全部者權限。即便與其餘條目匹配，它們也不會在命名用戶/組條目中接受任何權限。

若是用戶不是全部者，或者沒有 OWNER@ 項，但用戶標識有 ACE，則僅接受用戶標識的權限。即便這些組條目具備比用戶條目更廣的權限，它們也不會收到任何組的權限。用戶最多應匹配一個用戶項。

若是找不到匹配的用戶項，但存在項與一個或多個用戶組匹配，則強制執行將基於全部匹配組（包括全部者組）的 GROUP@ 項的權限。

若是找不到匹配的組，則將使用 EVERYONE@ 項的權限（若是存在）。

默認狀況下，若是用戶與 ACL 中的 ACE 不匹配，則訪問將被拒絕。

ACL 文件

接受 ACL 文件的工具但願它是一個簡單的文本文件，每行有一個 ACE。

能夠使用 # 做爲行上的第一個非空白字符，將該行標記爲註釋。

例如：

# ACL for my container
# Owner can't touch data - just do admin-type things
A::OWNER@:dtTaAo
# My project's users can generate and access data
A:G:my_great_project@:rw
# Bob can use the data to generate a report
A::bob@:r

權限位和 ACE 自己不須要按任何特定順序排列。可是，當 DAOS 解析和顯示 ACL 時，順序可能不一樣。

限制

DAOS ACL 內部的數據結構中 ACE 列表的最大大小爲 64KiB。

要計算 ACL 內部數據的大小，須要對每一個 ACE 使用如下公式：

ACE 的基本大小是 256 字節。
若是 ACE 主體不是特殊主體之一，
將 PRINCIPAL 字符串的長度 +1。
若是該值不是 64 字節對齊的，則擴展到最近的 64 字節邊界。