搭建应用服务器之STS Policy

上一篇文章中介绍了如何快速搭建应用服务器，在本文中会基于上文提到的应用服务器，以上海的Bucket app-base-oss为例子，配置不同的Policy以实现不同的权限控制。
以下说明中假设你已经开通了STS，并完全阅读了上一篇文章。以下提到的Policy都是指上文提到的config.json中指定的Policy文件的内容。
以下讲述的获取STS Token 后对OSS操作 指的是应用服务器指定Policy，从STS获取临时凭证后，应用通过临时凭证访问OSS。

常见Policy

完全授权的Policy

上文为了演示方便，默认Policy如下，表示的意思是允许应用对所有OSS的操作。
这对移动应用来说是不安全的授权，不推荐。

{
  "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

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

{
  "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中空间隔离的效果。

{
  "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

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

{
  "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中空间隔离的效果。

{
  "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

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

{
  "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的实现。

• 以上的Policy中的app-base-oss是本文使用的Bucket，如果在实际使用中需要替换成自己的Bucket。

更多参考资料

• RAM和STS在OSS中的使用指南
• OSS中的访问控制
• RAM官方文档和STS官方文档