Managing OpenStack access control lists using S3 API emulation
Use the following information to manage OpenStack ACLs using S3 API emulation..
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 the S3 API, see the Amazon S3 documentation.
The following information about S3 ACLs is only applicable if s3_acl is set to true in the proxy-server.conf file. If S3 API emulation enabled, s3_acl is set to true by default.
For a user to use the S3 API in IBM Spectrum Scale, the user must have a role defined for the swift project. Any role suffices, because for the S3 API there is no difference between the SwiftOperator role or others.
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 emulation 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.
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.
Container or objects created using the swift API are not accessible through the S3 API when the configuration flag allow_no_owner is set to false in proxy-server.conf. To change this setting, you can use the following command:
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.