对象存储手把手教一 | 用户数据访问控制管理 ACL

QingStor分布式存储

关注

发布于: 2 小时前

作者：QingStor 攻城狮陈孟超

从本周开始，我们将新增 “对象存储手把手教”系列的专题文章，介绍对象存储的实用功能，解决实际生产场景下的业务需求。同时，将会以 QingStor 对象存储为演示平台，介绍各类业务下的具体配置方法。

现在，就正式开始“对象存储手把手教”的第 1 期的分享了。

用户：最近在使用对象存储，数据倒是放上去了，但我的业务该怎么管理，总不能就只有管理员可以存取数据吧？

QingStor：别担心，对象存储的数据都存放在 Bucket（存储桶）中，可以通过 Bucket ACL 解决您的烦恼，让更多的人参与建设 Bucket，应用到更多的使用场景。

1. 什么是 ACL

ACL 即 Access Control Lists（访问控制列表）。这里说的 ACL 是指 Bucket ACL，是基于 Bucket（存储桶）资源的访问策略之一。使用 ACL 可以向其他用户授予读写权限。

ACL 本质上是基于存储桶维度的权限过滤器，通过自定义的一条或多条 ACL 策略规则，使 Bucket 所有者可以管理存储桶的访问权限。

可以通过存储桶 ACL 规则，定义哪些帐号被授予访问权限及权限的类型。当收到对存储桶资源的请求时，对象存储会检查 Bucket 的 ACL 规则来验证请求者是否具有对应的访问权限，达到用户级别的访问控制。

ACL 如一个仓库管理员，拿着个小本本，记录着哪些人可以进来参观随便看，哪些人可以进来存取东西但不能随便看，哪些人可以又看又拿，哪些人连门都不让进。

Bucket ACL 设计的初衷在于满足用户对不同场景下对 Bucket 不同粒度的控制，以满足用户不同的使用场景。

目前 Bucket 控制粒度有 ACL 与 Policy 两种。相比于 Policy， ACL 控制的粒度更粗犷更大一点更简单点，是在用户层面进行访问控制，决定哪些人可以以何种权限使用 Bucket；而 Policy 粒度更小，细致地指定 API 级别的控制，可以限制 API 的动作、访问来源等。

如果说 ACL 像个仓库管理员，那么 Policy 就像个仓库里的保安，拿着行为准则，在你进仓库后，告诉你能怎么看，能怎么碰，更细致的管控你的行为。

2. ACL 的结构

一个 Bucket ACL 可以认为由多个 AC（Access Control）规则组成，AC 规则结构如下：

{"grantee": {"type": "user or group","id": "userid or QS_ALL_USERS"},"permission": "READ or WRITE or FULL_CONTROL"}

复制代码

AC 规则包含两个结构：grantee 授权对象和 permission 权限

2.1 grantee 授权对象

授权对象分两类：user 和 group。

当为 user 时，授权的 user 是在系统（比如青云 QingCloud 公有云）注册的 user。一个 grantee 一次只能指定一个用户。需要注意的是，user 可以是主账户也可以是子账户，一个主账户可以有多个子账户，但主账户和子账户下的 Bucket 是独立控制的，并不因为子账户从属于主账户，导致子账户的 bucket 也能被主账户直接控制。

举个例子：主账户 A 名下有子账户 A_1, A_2，主账户 A 创建了 bucket-a，子账户 A_1 创建了 bucket-a-1，那么 A 具有 bucket-a 所属权，但没有 bucket-a-1 的所属权，同样 A_1 更没有 bucket-a 的所属权，但具有 bucket-a-1 的所属权。

授权给某个用户后，对象存储后台，会根据用户的 access key 判断是不是该用户，一个用户，可以有多个 access key。授权是用用户 ID，而不是 access key 。控制台配置时，可以用用户 ID 或用户注册的邮箱添加 ACL。

当为 group 时，意味着授权对象为一个群组，目前只支持 group 为 QS_ALL_USERS，授权对象为所有用户，此时用户可以是在系统注册的用户，也可以是未在系统注册的用户（即跳过用户身份验证的匿名用户）。

2.2 permission 权限

包括三种类型权限：

READ（读）可以读该 Bucket 中的数据。
WRITE（写）可以往该 Bucket 的上传、删除数据。
FULL_CONTROL（读写）拥有 READ 和 WRITE 权限，可读、上传、删除数据。

需要注意的是，ACL 不是 Bucket 中的数据，permission 权限仅针对该 Bucket 中存储的对象。因此一个 AC 规则结构，可以给 Bucket 添加一个 user 或者一个 group 的访问控制。可以给 Bucket 添加多个 AC 规则，组成 ACL 访问控制列表，结构如下：

{ "acl": [   {      "grantee": {        "type": "user or group",        "id": "userid or QS_ALL_USERS"      },      "permission": "(READ or WRITE) or FULL_CONTROL"   },    {      "grantee": {        "type": "user or group",        "id": "userid or QS_ALL_USERS"      },      "permission": "READ or WRITE or FULL_CONTROL"   },   ... ]}

复制代码

3. ACL 如何对 Bucket 进行控制

当创建 Bucket 时，其资源所属的账号将具有对资源的全部权限，该权限不可修改或删除。

当有一个请求想要访问某 Bucket，假设为 xx-bucket-a，QingStor 对象存储会根据 xx-bucket-a 拥有者（创建它的人）设置的 ACL，判断当前请求人是不是符合 ACL 中某个 AC 规则，如果符合则允许该请求，否则禁止该请求，从而现实访问控制。

多个 AC 规则之间的关系是并集关系，如 AC01 授予用户 A 读权限，AC02 授权用户 A 写权限，AC03 授予所有用户读权限，那么用户 A 的被授予的权限是 AC01 U AC02 U AC03 ，即读写权限。

举个例子：用户 usr-alice 创建了一个 Bucket 名为 bucket-alice 用来放一些数据，用户 usr-alice 有个同事或子账号 usr-bob，让他可以访问到存放的数据，于是想授权 usr-bob 读权限，usr-alice 可以在 bucket-alice 的 ACL 中增加一条规则，如下：

{  "grantee": {    "type": "user",    "id": "usr-bob"  },  "permission": "READ"}

复制代码

如此，usr-bob 可以读 bucket-alice 中的数据，但不能进行修改。

4. 使用场景

4.1. 搭建静态资源服务器

用户：我需要搭建几个静态资源服务器，一台只对内使用，只有我的 web 和 app 可去获取静态的资源（图片，html 等）；一台对公共开放，任何人可以通过 url 获取到共享的图片；管理员管理静态资源服务器。

QingStor ：首先，可以用主账户创建两个 Bucket，internal-static-b 和 shared-static-b，分别用于存放内部静态数据以及共享静态数据。

创建几个账户（比如青云 QingCloud 公有云账户）作为管理员，同时在这两个 Bucket ACL 中授予他们读写权限 (FULL_CONTROL)，因为读写权限便于管理数据，当然，如果数据过于敏感，可以只赋予写权限（WRITE），可以新增、删除、覆盖数据。

创建几个账户作为内部账号，用于提供给 web 和 app 进行访问 internal-static-b，在 internal-static-b ACL 中，授予内部账号读权限（READ）。之后，您的 web 和 app 应用的后端，可以通过内部账号的 access key，使用 API 读取 internal-static-b 中的数据。

在 shared-static-b ACL 中，授予所有用户（QS_ALL_USERS）读权限（READ）。

4.2. 存放海量用户数据

用户：我希望用户能通过我的 app 直接把数据存放在对象存储里，能直接从对象存储里读取数据，但不经过我的后台，减小后台数据压力，我该怎么做呢？

QingStor：其实很简单，您可以创建一个子账号，在需要存放用户数据的 Bucket 中，对这个子账号授予 ACL 读写权限，通知在您的 app 里，用该子账号的 access key 构建签名，访问该 Bucket 就是进行读写数据了。在为用户写数据的时候，可以将文件命名采用用户 ID + 时间戳 + 文件类型的格式，可以更加方便的读取某个用户的数据，同时写数据不与其他用户冲突。