All posts

The bucket was open, but it was never yours to change.

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. Ins

Free White Paper

Open Policy Agent (OPA) + End-to-End Encryption: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

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.

Continue reading? Get the full guide.

Open Policy Agent (OPA) + End-to-End Encryption: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

For teams using GitHub Actions, set the AWS role as the target for OpenID Connect (OIDC). This avoids long-lived secrets entirely. Your workflow.yml can pull data from S3 without ever storing a static key, even in encrypted secrets. It’s one less vector for risk, one more step in hardening your engineering workflow.

Read-only roles in AWS S3 also simplify compliance. They can be scoped to exact paths within a bucket, letting you serve different branches or services without overlap. From monorepos to microservices, each Git integration can be isolated, traceable, and reversible.

The outcome is a cleaner security posture, faster audits, and predictable automation that never writes what it shouldn’t. And the best part is how quickly you can see it in action.

You can have Git triggering AWS S3 reads securely, with roles locked to the byte, in minutes. See how this works in a live environment with hoop.dev—your gateway to building, testing, and shipping with cloud resources without the risk of over-permissioned access.

Get started

See hoop.dev in action

One gateway for every database, container, and AI agent. Deploy in minutes.

Get a demoMore posts