Give quickS3 the smallest key that works
What to grant the access key behind a connection and what to leave out, so a mistake anywhere stops at the buckets you picked.
Roles decide what each person can ask quickS3 to do. The access key decides what quickS3 can actually do at your provider. Keep the key narrow, so that even if something went wrong in quickS3, the damage stops at the buckets you chose.
What to grant
Start from nothing and add only what your team uses:
| Your team needs to | Give the key |
|---|---|
| Browse, preview, and download | List the bucket, read objects |
| Upload, create folders, delete | Write and delete objects |
| Have quickS3 set up browser uploads for you | Read and update the bucket’s CORS settings |
| See all buckets without typing their names | List all buckets |
| Create buckets from quickS3 | Create buckets (account-wide) |
Each provider guide shows what these are called there, and the AWS guide has a complete policy you can copy.
A few rules of thumb:
- Make a key used only by quickS3. Then you can rotate or revoke it without breaking anything else.
- Limit it to specific buckets wherever your provider allows. If it can’t list buckets as a result, type the names into Bucket scopes.
- Leave out bucket creation unless you really need it. A key that can create buckets can usually touch every bucket in the account.
- Skip the CORS permission if you’d rather set CORS yourself. The provider guides show the rule to add.
How the limits stack
Every action someone takes in quickS3 has to pass three checks, and the strictest one wins:
- The access key. If the key can’t delete, nobody can delete through quickS3, whatever their role says.
- The connection’s bucket scopes. Buckets left out of the scopes don’t show up in quickS3 at all.
- The person’s roles. Their Allow and Deny rules narrow things down to specific buckets and folders.
A role can only narrow what the key allows. It can never add to it.
Write includes delete
In quickS3, Write covers uploading, overwriting, deleting, and creating folders. There’s no separate “upload only” permission yet. If a bucket must never lose files, give its connection a key without delete permission, or turn on versioning at your provider so deleted files can be recovered there.