How to manage the OpenStack S3 API
The following topic lists the permissions and the known limitations of S3 API.
IBM Spectrum Scale supports S3 access control lists (ACLs) for buckets and objects. These S3 ACLs are stored separately from the ACLs that are set through the Swift API or the ACLs stored in the file system (NFSv4 or POSIX).
You can set and query ACLs through S3 API. For more information, see the Amazon S3 documentation.
If the S3 API is enabled, the default value of s3_acl in the proxy-server.conf file is true. The S3 API uses its own metadata for an ACL. The metadata includes the X-Container-Sysmeta-Swift3-Acl, which is used to achieve the best S3 compatibility.
However, if the S3 API is set to false, the S3 API initially uses Swift ACLs (such as the X-Container-Read ACL) initially instead of S3 ACLs.
To use the S3 API in IBM Spectrum
Scale, you must have a role
that is defined for the swift project. Any role suffices because for the S3 API there is no
difference between the SwiftOperator role or other roles.
The owner of a resource is implicitly granted FULL_CONTROL instead of just READ_ACP and WRITE_ACP. Granting this control is safe (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 is required. |
| HEAD object | READ permission on object or as object owner is required. |
| GET object | READ permission on object or as object owner is required. |
| DELETE object | WRITE permission on bucket or as bucket owner is required. |
| Get object ACL (GET on ACL subresource) | READ_ACP permission on object or as object owner is required. |
| Set object ACL (PUT on ACL subresource) | WRITE_ACP permission on object or as object owner is required. |
| 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 is required. |
| GET bucket | READ permission on bucket or as bucket owner is required. |
| DELETE bucket | It must be the bucket owner. |
| Get bucket ACL (GET on ACL subresource) | READ_ACP permission on bucket or as bucket owner is required. |
| Set bucket ACL (PUT on ACL subresource) | WRITE_ACP permission on bucket or as bucket owner is required. |
Known limitations for S3 API support
- The OpenStack Swift S3 API implements a limited set of the functions that are provided by the Amazon S3 API. For more information, see the OpenStack S3 compatibility matrix: https://docs.openstack.org/swift/latest/s3_compat.html
- The OpenStack Swift S3 API maps S3 buckets to Swift containers. High transaction throughput to a S3 bucket might experience performance issues because of container limitations. To avoid these performance issues, spread the requests among many buckets to avoid the underlying containers from being overloaded.
- 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 (which is not possible for unauthorized requests).
- You cannot specify S3 ACL grantees by email.
- Grantees in the ACL are not validated. So, any name can be used, including names for users that do not exist.
- The S3 ACLs are not supported in the Objects page of the IBM Spectrum Scale GUI.
- Container or objects that are created by using the Swift API are not accessible through S3 API
when the allow_no_owner configuration flag is set to false in the
proxy-server.conf file. To change this setting, you 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 is not implemented.