Managing OpenStack access control lists using S3 API
The following topic lists the permissions and the known limitations of S3 API.
IBM Spectrum Scale™ supports S3 access control lists (ACLs) on buckets and objects. These S3 ACLs are stored separately from the ACLs set through the Swift API and the ACLs stored in the file system (NFSv4 or POSIX). For information on how to set and query ACLs through S3 API, see the Amazon S3 documentation.
If S3 API is enabled, the default value of s3_acl in the proxy-server.conf file is true. S3 API uses its own metadata for ACL, such as X-Container-Sysmeta-Swift3-Acl, to achieve the best S3 compatibility. However, if S3 API is set to false, S3 API tries Swift ACLs, such as X-Container-Read, initially instead of S3 ACLs.
For a user to use S3 API in IBM Spectrum Scale, the user must have a role defined for the swift project. Any role suffices, because for S3 API there is no difference between the SwiftOperator role or others.
The owner of a resource is implicitly granted FULL_CONTROL instead of just READ_ACP and WRITE_ACP. This is not a security issue because with WRITE_ACP, the owners can grant themselves FULL_CONTROL access.
The following table lists the required permissions for S3 operations.
S3 operation | Required permission |
---|---|
PUT object | WRITE permission on bucket or as bucket owner |
HEAD object | READ permission on object or as object owner |
GET object | READ permission on object or as object owner |
DELETE object | WRITE permission on bucket or as bucket owner |
Get object ACL (GET on ACL subresource) | READ_ACP permission on object or as object owner |
Set object ACL (PUT on ACL subresource) | WRITE_ACP permission on object or as object owner |
Create bucket (PUT) | Any user with a role on the project can create a bucket. |
HEAD bucket | READ permission on bucket or as bucket owner |
GET bucket | READ permission on bucket or as bucket owner |
DELETE bucket | bucket owner |
Get bucket ACL (GET on ACL subresource) | READ_ACP permission on bucket or as bucket owner |
Set bucket ACL (PUT on ACL subresource) | WRITE_ACP permission on bucket or as bucket owner |
Known limitations for S3 API support
Unauthorized S3 requests are not supported. S3 requests do not contain a reference to the account, and the object server derives the account information from the authorization information. This is not possible for unauthorized requests.
Specifying S3 ACL grantees by email is not supported.
Grantees in ACL are not validated. Therefore, any name can be used, even users that do not exist.
Container or objects created using the swift API are not accessible through S3 API when the allow_no_owner configuration flag is set to false in proxy-server.conf. To change this setting, you can use the following command:
The default value of the allow_no_owner configuration flag is true.mmobj config change --ccrfile proxy-server.conf --section filter:swift3 --property allow_no_owner --value true
- The POST operation to update metadata has not been implemented.