Locking down AWS S3 with read-only roles is simple in theory but dangerous if done wrong. One missed policy, one wrong trust relationship, and your data becomes writable to the wrong hands. That’s where AWS IAM roles, S3 permissions, and Okta group rules work together to form a clean, controlled access path.
An AWS S3 read-only role starts with IAM. Create a role that grants only the s3:Get* and s3:List* actions. No Put, no Delete. Scope it to the right buckets with the least privilege possible. Add a trust policy to allow Okta’s AWS integration to assume it. This trust policy should point only to the AWS SAML provider configured with Okta.
Okta group rules are the glue. With Okta group rules, you can match user attributes or group memberships to push them into a specific AWS role. Build a rule where membership in your "S3-ReadOnly"Okta group maps directly to the S3 read-only IAM role. Use Okta’s "Group to Role"mapping to connect the dots without manual assignments.
Test it. Log in through Okta, assume the role, and try both read and write actions. Reads and lists should pass. Writes should fail hard. Review CloudTrail logs for each test. Keep the mapping visible to both your identity and cloud teams so no one silently escalates permissions.