本文基于30分钟快速搭建移动应用直传服务 中提到的应用服务器,以上海的Bucket app-base-oss 为例,讲解如何配置不同的Policy实现不同的权限控制。
说明
  • 以下说明中假设您已经开通了STS,并完全阅读了30分钟快速搭建移动应用直传服务

  • 以下提到的Policy都是上文提到的config.json中指定的Policy文件的内容。

  • 以下讲述的获取STS Token 后对OSS的操作是指为应用服务器指定Policy,从STS获取临时凭证后,应用通过临时凭证访问OSS。

常见Policy

  • 完全授权的Policy

    为了演示方便,默认Policy如下,表示允许应用可以对OSS进行任何操作。

    说明
    这对移动应用来说也是不安全的授权,不推荐。
    ```json
      {
        "Statement": [
          {
            "Action": [
              "oss:*"
            ],
            "Effect": "Allow",
            "Resource": ["acs:oss:*:*:*"]
          }
        ],
        "Version": "1"
      }
      ```
    获取STS Token 后对OSS操作 结果
    列出所有创建的Bucket 成功
    上传不带前缀的Object,test.txt 成功
    下载不带前缀的Object, test.txt 成功
    上传带前缀的Object, user1/test.txt 成功
    下载带前缀的Object, user1/test.txt 成功
    列出Object, test.txt 成功
    带前缀的Object, user1/test.txt 成功
  • 不限制前缀的只读不写Policy

    这个Policy表示,应用可以对Bucket app-base-oss下所有的Object可列举,可下载。

    ```json
      {
        "Statement": [
          {
            "Action": [
              "oss:GetObject",
              "oss:ListObjects"
            ],
            "Effect": "Allow",
            "Resource": ["acs:oss:*:*:app-base-oss/*", "acs:oss:*:*:app-base-oss"]
          }
        ],
        "Version": "1"
      }
      ```
    获取STS Token 后对OSS操作 结果
    列出所有创建的Bucket 失败
    上传不带前缀的Object,test.txt 失败
    下载不带前缀的Object, test.txt 失败
    上传带前缀的Object, user1/test.txt 失败
    下载带前缀的Object, user1/test.txt 失败
    列出Object, test.txt 失败
    带前缀的Object, user1/test.txt 失败
  • 限制前缀的只读不写Policy

    这个Policy表示,应用可以对Bucket app-base-oss下带有前缀user1/的Object可列举,可下载。但无法下载其他前缀的Object。这样不同的应用如果对应不同的前缀,就可以达到在同一个bucket中空间隔离的效果。

    ```json
      {
        "Statement": [
          {
            "Action": [
              "oss:GetObject",
              "oss:ListObjects"
            ],
            "Effect": "Allow",
            "Resource": ["acs:oss:*:*:app-base-oss/user1/*", "acs:oss:*:*:app-base-oss"]
          }
        ],
        "Version": "1"
      }
      ```
    获取STS Token 后对OSS操作 结果
    列出所有创建的Bucket 失败
    上传不带前缀的Object,test.txt 失败
    下载不带前缀的Object, test.txt 失败
    上传带前缀的Object, user1/test.txt 失败
    下载带前缀的Object, user1/test.txt 成功
    列出Object, test.txt 成功
    带前缀的Object, user1/test.txt 成功
  • 不限制前缀的只写不读Policy

    这个Policy表示,应用可以对Bucket app-base-oss 下所有的Object进行上传。

    ```json
      {
        "Statement": [
          {
            "Action": [
              "oss:PutObject"
            ],
            "Effect": "Allow",
            "Resource": ["acs:oss:*:*:app-base-oss/*", "acs:oss:*:*:app-base-oss"]
          }
        ],
        "Version": "1"
      }
      ```
    获取STS Token 后对OSS操作 结果
    列出所有创建的Bucket 失败
    上传不带前缀的Object,test.txt 成功
    下载不带前缀的Object, test.txt 失败
    上传带前缀的Object, user1/test.txt 成功
    下载带前缀的Object, user1/test.txt 成功
    列出Object, test.txt 成功
    带前缀的Object, user1/test.txt 成功
  • 限制前缀的只写不读Policy

    这个Policy表示,应用可以对Bucket app-base-oss 下带有前缀user1/的Object进行上传。但无法上传其他前缀的Object。这样不同的应用如果对应不同的前缀,就可以达到在同一个bucket中空间隔离的效果。

    ```json
      {
        "Statement": [
          {
            "Action": [
              "oss:PutObject"
            ],
            "Effect": "Allow",
            "Resource": ["acs:oss:*:*:app-base-oss/user1/*", "acs:oss:*:*:app-base-oss"]
          }
        ],
        "Version": "1"
      }
      ```
    获取STS Token 后对OSS操作 结果
    列出所有创建的Bucket 失败
    上传不带前缀的Object,test.txt 失败
    下载不带前缀的Object, test.txt 失败
    上传带前缀的Object, user1/test.txt 失败
    下载带前缀的Object, user1/test.txt 成功
    列出Object, test.txt 失败
    带前缀的Object, user1/test.txt 失败
  • 不限制前缀的读写Policy

    这个Policy表示,应用可以对Bucket app-base-oss下所有的Object进行列举、下载、上传和删除。

    ```json
      {
        "Statement": [
          {
            "Action": [
              "oss:GetObject",
              "oss:PutObject",
              "oss:DeleteObject",
              "oss:ListParts",
              "oss:AbortMultipartUpload",
              "oss:ListObjects"
            ],
            "Effect": "Allow",
            "Resource": ["acs:oss:*:*:app-base-oss/*", "acs:oss:*:*:app-base-oss"]
          }
        ],
        "Version": "1"
      }
      ```
    获取STS Token 后对OSS操作 结果
    列出所有创建的Bucket 失败
    上传不带前缀的Object,test.txt 成功
    下载不带前缀的Object, test.txt 成功
    上传带前缀的Object, user1/test.txt 成功
    下载带前缀的Object, user1/test.txt 成功
    列出Object, test.txt 成功
    带前缀的Object, user1/test.txt 成功
  • 限制前缀的读写Policy

    这个Policy表示,应用可以对Bucket app-base-oss下带有前缀user1/的Object进行列举、下载、上传和删除。但无法对其他前缀的Object进行读写。这样不同的应用如果对应不同的前缀,就可以达到在同一个bucket中空间隔离的效果

    {
        "Statement": [
          {
            "Action": [
              "oss:GetObject",
              "oss:PutObject",
              "oss:DeleteObject",
              "oss:ListParts",
              "oss:AbortMultipartUpload",
              "oss:ListObjects"
            ],
            "Effect": "Allow",
            "Resource": ["acs:oss:*:*:app-base-oss/user1/*", "acs:oss:*:*:app-base-oss"]
          }
        ],
        "Version": "1"
      }
    获取STS Token 后对OSS操作 结果
    列出所有创建的Bucket 失败
    上传不带前缀的Object,test.txt 失败
    下载不带前缀的Object, test.txt 失败
    上传带前缀的Object, user1/test.txt 成功
    下载带前缀的Object, user1/test.txt 成功
    列出Object, test.txt 成功
    带前缀的Object, user1/test.txt 成功

小结

从上面的例子可以看出:

  • 可以根据不同的应用场景制定不同的Policy,然后对应用服务器稍作修改就可以实现对不用的应用用户实现不同的权限控制。
  • 也可以在应用端做优化,在STS Token过期之前不需要向应用服务器再次请求。
  • Token实际是由STS颁发的,应用服务器相当于定制了Policy,向STS请求Token,然后将Token转发给应用。这里的Token是一个简略的说法。实际上包含了“AccessKeyId”、“AccessKeySecret”、“Expiration”、“SecurityToken”,这些在OSS提供给应用的SDK中会用到。详细参见各个SDK的实现。