ACL(访问控制列表)

最近更新时间:2021-11-10 13:56:38

查看PDF

KS3使用ACL(Access Control List : 访问控制列表)方便用户管理存储空间(Bucket)和文件(Object)的访问权限,每个Bucket和Object都拥有一个ACL,可以通过设置ACL定义向哪些用户授予哪些访问权限。

当KS3收到针对某个资源的请求后,将检查相应的ACL以验证请求者是否拥有所需的访问权限。

ACL使用XML格式来表示,示例:

<AccessControlPolicy>
    <Owner>
       <ID>Owner-User-Id</ID>
       <DisplayName>Owner-User-Name</DisplayName>
    </Owner>
    <AccessControlList>
      <Grant>
        <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
          <ID>User2-Id</ID>
          <DisplayName>User2-Name</DisplayName>
        </Grantee>
        <Permission>READ</Permission>
     </Grant>
...
    </AccessControlList>
</AccessControlPolicy>

示例中Owner元素中需要设置资源拥有者的账户ID和用户名,Grant元素中需要设置被授权人的账户ID和用户名,以及所授予的权限。下面依次对被授权人、授予的权限、预设ACL的方式以及KS3支持操作ACL的方式进行说明。

被授权者

被授权者可以是KS3账户也可以是所有用户(包括匿名用户),但不能是IAM子用户。

  • KS3账户:在授权语句中,使用账户ID和用户名来表示被授权的KS3账户。
<Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser"><ID>ID</ID><DisplayName>GranteesEmail</DisplayName>
</Grantee>
  • 所有用户(包含匿名用户):在授权语句中,使用http://acs.ksyun.com/groups/global/AllUsers表示授权所有用户。
<Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group"><URI>http://acs.ksyun.com/groups/global/AllUsers</URI></Grantee>

授予的权限

下表列出了KS3在ACL中支持的权限集。

ACL权限 对存储空间授权 对文件授权
READ 允许被授权者列出存储空间中的文件 允许被授权者读取文件数据及其元数据
WRITE 允许被授权者创建、覆盖和删除存储空间(Bucket)中的任意文件 不适用
FULL_CONTROL 授予被授权者在存储空间(Bucket)上的READ、WRITE 权限 授予被授权者在文件上的READ权限

注意:
1、对于文件ACL和存储空间ACL,ACL权限集相同,但这些ACL权限授予允许被授权者进行的具体操作不同,例如存储空间ACL的READ权限允许被授权者列出存储空间中的文件,而文件ACL的权限则是允许被授权者读取文件数据及其元数据。

2、文件ACL不支持WRITE权限。

ACL的每个权限允许一个或多个 KS3 操作,例如:文件的读权限,包含了Head Object和GET Object等KS3操作。 下表展示了每个ACL权限允许的具体操作。ACL 主要用于授予基本读/写权限,这与文件系统权限类似。

ACL权限 在Bucket授予ACL权限时允许的操作 在Objetc授予ACL权限时允许的操作
READ List Bucket,List Multipart Upload Get Object,Head Object, List Parts
WRITE Put Object, Post Object, Put Object Copy, Upload Part Copy,Delete Object,Initiate Multipart Upload, Upload Part, Complete Multipart Upload, Abort Multipart Upload 不适用
FULL_CONTROL 等同于授予READ和WRITE ACL权限 等同于授予READ ACL权限。

预设ACL权限

KS3支持在创建桶或上传对象时通过头域设置桶或对象的权限控制策略,这种方式设置的权限称为预设ACL。
使用预设 ACL 时,需要在 PUT Bucket/Object 或 PUT Bucket/Object acl 中携带相应的头部,这些头部中x-kss-acl只能对所有用户进行授权,x-kss-grant-read、x-kss-grant-write和x-kss-grant-full-control可以更细粒度地对指定用户授权。

  • 存储空间预设ACL

存储空间预设ACL可选择的头部有4个,描述和示例见下表:

头域 描述 示例
x-kss-acl 设置任何用户(包括匿名用户)的操作权限,取值包括:private、public-read、public-read-write,默认值为private:
  • private:私有,空间所有者拥有所有的访问权限。其他人没有访问权限(默认);
  • public-read:公开读,空间所有者拥有所有的访问权限,任何用户(包括匿名用户)都拥有列举空间下所有文件的权限;
  • public-read-write:公开读写,任何用户(包括匿名用户)都可以向存储空间写入文件、删除文件、列举空间下所有文件的权限;
指定任何用户(包括匿名用户)都拥有列举空间下所有文件的权限:
  • x-kss-acl:public-read
x-kss-grant-read 为若干用户授予READ权限 给id为1234578和3344211的两个用户授予READ权限:
  • x-kss-grant-read:id=“1234578”,id=“3344211”
x-kss-grant-write 为若干用户授予WRITE权限 给id为1234578和3344211的两个用户授予WRITE权限:
  • x-kss-grant-write:id=“1234578”,id=“3344211”
x-kss-grant-full-control 为若干用户授予FULL_CONTROL权限 给id为1234578和3344211的两个用户授予FULL_CONTROL权限:
  • x-kss-grant-full-control:id=“1234578”,id=“3344211”
  • 文件预设ACL

文件预设ACL可选择的头部有3个,描述和示例见下表:

头域 描述 示例
x-kss-acl 设置任何用户(包括匿名用户)的操作权限,取值包括:private、public-read,默认值为private:
  • private:私有,文件所有者拥有所有的访问权限。其他人没有访问权限(默认);
  • public-read:公开读,所有用户(包括匿名用户)拥有文件的访问权限;
指定任何用户(包括匿名用户)都拥有文件的访问权限:
  • x-kss-acl:public-read
x-kss-grant-read 为若干用户授予READ权限 给id为1234578和3344211的两个用户授予READ权限:
  • x-kss-grant-read:id=“1234578”,id=“3344211”
xx-kss-grant-full-control 为若干用户授予FULL_CONTROL权限 给id为1234578和3344211的两个用户授予FULL_CONTROL权限:
  • x-kss-grant-full-control:id=“1234578”,id=“3344211”

操作方式

支持控制台和API两种操作方式:

操作方式 参考文档
控制台
  • 控制台空间管理-权限设置
  • 控制台内容管理-文件管理
  • API 用户在创建存储空间或上传对象时:用户可以在请求头中通过设置以下的请求头来指定ACL,详情请见:用户在已有资源上设置ACL:可以在请求头或者在请求内容中中设置,详情请见:
    SDK
  • JAVA
  • PHP
  • Python
  • Android
  • IOS
  • JavaScript
  • Node.js
  • C#
  • Go
  • 文档内容是否对您有帮助?

    根本没帮助
    文档较差
    文档一般
    文档不错
    文档很好

    在文档使用中是否遇到以下问题

    内容不全,不深入
    内容更新不及时
    描述不清晰,比较混乱
    系统或功能太复杂,缺乏足够的引导
    内容冗长

    更多建议

    0/200

    评价建议不能为空

    提交成功!

    非常感谢您的反馈,我们会继续努力做到更好!

    问题反馈