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 访问时将被拒绝。

拒绝访问
- 目前，只支持设置“允许”访问控制项。
- 但是，可以通过为没有权限的特定用户创建允许条目来拒绝对其的访问。这与删除用户的 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 字节边界。

debugzhang

DAOS 分布式异步对象存储｜安全模型

验证