DAOS 分散式非同步物件儲存｜安全模型

debugzhang發表於2021-04-04

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

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

DAOS 從兩個方面實現自己的安全層：

在使用者級別，客戶端只能讀取和修改被授予訪問許可權的 Pool 和 Container。
在系統和管理級別，只有經過授權的元件才能訪問 DAOS 管理網路。

驗證

有不同的身份驗證方法，這取決於呼叫者是訪問客戶端資源還是 DAOS 管理網路。

客戶端庫

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

受信任的 DAOS 代理程式 daos_agent 在每個客戶端節點上執行，並對使用者程式進行身份驗證。

DAOS 安全模型的設計支援客戶端程式的不同身份驗證方法。目前，我們只支援 AUTH_SYS 身份驗證。

DAOS 管理網路

每個受信任的 DAOS 元件（daos_server、daos_agent 和 dmg 管理工具）都通過為該元件生成的證書進行身份驗證。這些元件通過相互認證的 TLS 在 DAOS 管理網路上相互標識。

授權

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

元件證書

對 DAOS management RPCs 的訪問是通過設定每個管理元件證書中的 CommonName (CN) 進行控制的。給定的 management RPC 只能由與正確證書連線的元件呼叫。

訪問控制列表

客戶端對 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 位元組邊界。