That’s how I learned the hard way that AWS S3 permissions are not just a checkbox—they are the walls, doors, and locks around your data. When you need to grant access without the risk of accidental deletion or overwrite, a read‑only role is the only sane path. Many teams overlook this when working in Community Edition setups, but it’s just as important here as in any enterprise-scale deployment.
An AWS S3 read‑only role lets you expose data safely, letting users retrieve objects without the ability to change or destroy them. You define the policy, attach it to a role, and scope it tightly to the buckets or prefixes you choose. The key is least privilege: enough access to do the job, nothing more.
A simple policy for full read‑only access to a specific bucket looks like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::your-bucket-name",
"arn:aws:s3:::your-bucket-name/*"
]
}
]
}
This grants permission to list the bucket and fetch objects—but not delete, overwrite, or upload. If you need access only to a specific folder inside the bucket, you scope the Resource to that prefix.