S3 API compatibility

Object Storage answers the Amazon S3 API at each region's endpoint. These tables list what an S3 client can do with each kind of access key, how the request features behave, and what the dashboard does without a key. An operation the page does not list may or may not work, so try it on a test bucket before you rely on it.

A key is Read only or Read and write, and works on one bucket or on all your buckets (What a key can do). A request outside its permissions or its scope answers 403 AccessDenied.

Temporary credentials do what a key of the same permissions does with objects, and nothing with a bucket's settings: they cannot read them either (Create temporary credentials).

ListBuckets lists only the buckets in the key's scope, so a key limited to one bucket lists that bucket alone. Such a key gets 403 AccessDenied from every other bucket, also as the source of a CopyObject.

DeleteObjects with a read only key answers 200 and deletes nothing. Each key comes back under Errors with the code AccessDenied, so read Errors as well as the status.

SelectObjectContent and RestoreObject answer 405 MethodNotAllowed with any key.

Create and delete buckets, and change their settings, in the dashboard or through the Coritan API (Create and delete buckets). No key can.

A request signed with your key that changes a bucket or object setting answers 403 AccessDenied with the message Change this setting in the dashboard or the Object Storage API. The settings are versioning, CORS, lifecycle rules, Object Lock, retention, legal holds, policies, ACLs, encryption, website, notifications, replication and logging. Change them here instead:

• Versioning and Object Lock: Versioning and Object Lock.
• CORS: CORS rules.
• Lifecycle rules: Lifecycle rules.
• Encryption: Encrypt the objects in a bucket. No key can read the encryption setting either.

Reading a setting works with any key, as the table above shows. Object tags are yours to write with a read and write key.

Upload with your own 256-bit key in the x-amz-server-side-encryption-customer-* headers, and every read of the object needs the same key. In boto3, pass SSECustomerAlgorithm="AES256" and SSECustomerKey to put_object, get_object and head_object.

Default encryption for a whole bucket is separate: Encrypt the objects in a bucket. A PutObject that asks for x-amz-server-side-encryption: AES256 works once default encryption is available, and can answer 500 InternalError until then.

An HTML form can upload a file straight to a bucket with a POST policy that you sign with a read and write key, such as one from boto3's generate_presigned_post. The form posts to the bucket's URL, such as https://s3.fra.coritan.com:7337/u7-assets.

ACLs are off on every bucket. An upload with x-amz-acl: public-read or an x-amz-grant-* header succeeds, and the object stays private: a request without a signature still answers 403. To share one object, send a presigned URL.

The object browser on a bucket's page uses none of your keys, because we sign each of its requests. It lists objects, uploads files with one request for each file, downloads them, creates folders, and deletes objects and folders (Upload, download and delete objects). Everything else on this page needs an S3 client and a key (Connect an S3 client).

• Connect an S3 client
• Create and revoke access keys
• Object Storage limits
• Troubleshoot Object Storage