Access keys
An access key is an access key ID and a secret key. The secret is shown once, when the key is created or rotated, and is never retrievable afterwards. If you lose it, rotate the key.
Create and manage keys in the portal under Storage → Access keys.
Two things a key carries
Every key has two independent settings:
- Scope: which buckets it may touch. A key can be limited to named buckets, or left unscoped so it reaches every bucket in your account, including ones you create later.
- Access level: what it may do on each of those buckets.
A scoped key sets a level per bucket, so one key can be read-write on app-uploads and read-only on app-assets. An unscoped key has a single level that applies to the whole account.
Access levels
| Level | Can do | Cannot do |
|---|---|---|
| Read only | Download and list objects | Upload, delete, change settings |
| Write only | Upload objects, including multipart uploads | Download, list, delete |
| Read and write | Everything read-only and write-only can, plus delete objects | Change bucket settings |
| Full | Everything, plus bucket settings such as CORS |
These are not a simple ladder. Read-and-write can delete objects, which neither read-only nor write-only can. Picking write-only is not "read-and-write minus reading": it is a drop box, and it cannot delete either.
Which to use
- Read only for anything serving or syncing files outward: a CDN puller, a read replica, a reporting job.
- Write only for anything that only ever submits data: a backup agent, an upload endpoint in your application, a log shipper. A leaked write-only key cannot read back what is already stored, and cannot delete it.
- Read and write for a general application key.
- Full only where CORS needs to be changed programmatically. Most applications never need it.
Public buckets are readable by anyone
If a bucket is public, its objects can be downloaded without any key at all. Giving a key write-only access to a public bucket does not stop that key, or anyone else, from reading those objects. The level governs authenticated access; the public switch is a separate and much broader grant.
Operation reference
What each level permits, by S3 operation.
| Operation | Read only | Write only | Read and write | Full |
|---|---|---|---|---|
HeadBucket, GetBucketLocation | yes | yes | yes | yes |
GetObject, HeadObject | yes | no | yes | yes |
ListObjectsV2, ListObjectVersions | yes | no | yes | yes |
PutObject, CopyObject (target) | no | yes | yes | yes |
| Multipart upload, including abort | no | yes | yes | yes |
DeleteObject, DeleteObjects | no | no | yes | yes |
GetBucketCors | yes | no | yes | yes |
PutBucketCors, DeleteBucketCors | no | no | no | yes |
CopyObject touches two buckets and needs both rights: read on the source and write on the target. If a key holds different levels on the two buckets, both have to permit their side.
Changing a key's access
Editing a key's scope or levels takes effect within 5 minutes. If you have just narrowed a key and are testing it, allow for that before concluding it did not work.
Deleting a key takes effect the same way. To cut off access immediately and permanently, delete the key and rotate anything that shared its secret.
What happens when access is denied
A request the key is not permitted to make returns 403 AccessDenied.
A request against a bucket outside the key's scope returns 404 NoSuchBucket, the same as a bucket that does not exist. That is deliberate: a scoped key cannot be used to discover which buckets your account has.
Unsupported operations
Some bucket-level S3 operations are not available and return 501 NotImplemented at every access level:
PutBucketAcl, PutBucketPolicy, PutBucketVersioning, PutBucketLifecycle, PutBucketEncryption, PutBucketWebsite, PutBucketNotification, PutBucketReplication, Object Lock, PutPublicAccessBlock, PutBucketLogging, bucket tagging, and their Get/Delete counterparts.
Use the portal for the settings that are configurable: public access, and CORS via PutBucketCors.