注意
本文档适用于 Ceph 的开发版本。
身份验证和ACLs
对 RADOS Gateway (RGW) 的请求可以是经过身份验证的，也可以是未经身份验证的。RGW 假定未经身份验证的请求是由匿名用户发送的。RGW 支持预设的 ACL。
认证
请求通过 AWS Signature 进行身份验证，该签名源自用户的凭证（S3 访问密钥和秘密密钥）。
大多数 S3 客户端和 AWS SDK 会为您生成这些签名，前提是提供了必要的凭证。在发出原始 HTTP 请求时，必须手动添加这些签名。
AWS Signature v4
请参阅官方文档 验证请求 (AWS Signature Version 4)。
支持以下 x-amz-content-sha256 请求头的值
实际有效载荷校验和值
UNSIGNED-PAYLOAD
STREAMING-UNSIGNED-PAYLOAD-TRAILER
STREAMING-AWS4-HMAC-SHA256-PAYLOAD
STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER
AWS Signature v2
请参阅官方文档 验证请求 (AWS Signature Version 2)。
注意
虽然 AWS 已弃用 v2 签名，但 RGW 继续支持它们。
针对 OpenStack Keystone 的身份验证
在配置了针对 OpenStack Keystone 进行身份验证的 radosgw 实例中，可以将 Keystone 用作 S3 API 身份验证的权威来源。为此，您必须设置
在 与 OpenStack Keystone 集成 中解释的
rgw keystone配置选项，rgw s3 auth use keystone = true.
此外，希望使用 S3 API 的用户必须获取 AWS 样式的访问密钥和秘密密钥。他们可以使用 openstack ec2 credentials create 命令来完成此操作
$ openstack --os-interface public ec2 credentials create
+------------+---------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------+---------------------------------------------------------------------------------------------------------------------------------------------+
| access | c921676aaabbccdeadbeef7e8b0eeb2c |
| links | {u'self': u'https://auth.example.com:5000/v3/users/7ecbebaffeabbddeadbeefa23267ccbb24/credentials/OS-EC2/c921676aaabbccdeadbeef7e8b0eeb2c'} |
| project_id | 5ed51981aab4679851adeadbeef6ebf7 |
| secret | ******************************** |
| trust_id | None |
| user_id | 7ecbebaffeabbddeadbeefa23267cc24 |
+------------+---------------------------------------------------------------------------------------------------------------------------------------------+
然后，生成的访问密钥和秘密密钥可用于对 radosgw 的 S3 API 访问。
注意
请注意，大多数针对 OpenStack Keystone 进行身份验证的生产 radosgw 部署也设置为 RGW 多租户，这对于 S3 签名 URL 和公共读取 ACL 有特殊的考虑因素。
访问控制列表 (ACLs)
RGW 支持与 S3 兼容的 ACL 功能。ACL 是访问授权的列表，指定用户可以对存储桶或对象执行哪些操作。每个授权在应用于存储桶时与应用于对象时具有不同的含义
Permission |
Bucket |
对象 |
|---|---|---|
|
被授权者可以列出存储桶中的对象。 |
被授权者可以读取对象。 |
|
被授权者可以写入或删除存储桶中的对象。 |
N/A |
|
被授权者可以读取存储桶 ACL。 |
被授权者可以读取对象 ACL。 |
|
被授权者可以写入存储桶 ACL。 |
被授权者可以写入对象 ACL。 |
|
被授权者对存储桶中的对象拥有全部权限。 |
被授权者可以读取或写入对象 ACL。 |
在内部，S3 操作被映射到 ACL 权限，如下所示
操作 |
Permission |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
某些映射（例如 s3:CreateBucket 到 WRITE）不适用于 S3 操作，但当 Swift 和 S3 访问相同资源时（例如当 Swift 用户 ACL 生效时）是必需的。这是在可能的情况下应使用 S3 存储桶策略而不是 S3 ACL 的众多原因之一。