Working with Git, AWS, and S3 often means finding the perfect balance between access and safety. Too much access, and risk spreads fast. Too little, and your workflows break. That’s why teams turn to AWS S3 read-only roles—tight, precise, and built for controlled visibility without the danger of unwanted writes or deletes.
A Git repository that interacts with AWS S3 should never need admin keys for simple tasks like fetching assets, reading configuration, or syncing datasets for local work. Instead of piping in full-blown IAM users, assign your Git workflows an AWS IAM role that allows s3:GetObject and little else. This is the core of the read-only principle: least privilege by design.
To set this up, start by creating an IAM policy with exact permissions. For one bucket, that means:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::your-bucket-name/*"
]
}
]
}
Attach this policy to an IAM role with a trusted entity—often your CI/CD system if you’re running automated Git pipelines. Use aws sts assume-role in jobs or pipelines to fetch short-lived credentials. This keeps access ephemeral, secure, and audit-friendly.