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 字节边界。