All posts

Kubernetes Ingress to AWS S3: How to Set Up Secure Read-Only IAM Roles

The pod kept failing every time it tried to list files in S3. It wasn’t the network. It wasn’t the code. It was IAM. If you run Kubernetes with Ingress routing to services that need to read from AWS S3, the fastest way to stop permissions hell is to set up read-only roles right. Done wrong, you risk over-permissive policies or broken access. Done right, you get a clean, secure path from your cluster to S3 without giving anything more than what’s necessary. 1. Map the trust Each Kubernetes wor

Free White Paper

AWS IAM Policies + Read-Only Root Filesystem: The Complete Guide

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

Free. No spam. Unsubscribe anytime.

The pod kept failing every time it tried to list files in S3.

It wasn’t the network. It wasn’t the code. It was IAM.

If you run Kubernetes with Ingress routing to services that need to read from AWS S3, the fastest way to stop permissions hell is to set up read-only roles right. Done wrong, you risk over-permissive policies or broken access. Done right, you get a clean, secure path from your cluster to S3 without giving anything more than what’s necessary.

1. Map the trust
Each Kubernetes workload that needs S3 read access must assume a role designed only for that task. On AWS, this means creating an IAM Role with an S3 policy scoped down to the exact bucket and prefix. Use s3:GetObject and s3:ListBucket only. No writes. No deletes.

2. Bind the role to the pod
If your cluster runs in EKS, use IAM Roles for Service Accounts (IRSA). Create a service account in the target namespace. Annotate it with the ARN of your read-only role. This ensures only pods using that account can pull objects from the bucket.

Continue reading? Get the full guide.

AWS IAM Policies + Read-Only Root Filesystem: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

3. Wire the Ingress cleanly
Ingress does not talk to S3 directly. Keep it routing traffic into your app service. Inside the cluster, your application pod uses the AWS SDK or CLI to fetch S3 objects over the role credentials provided by IRSA. No static keys. No secrets in ConfigMaps.

4. Test before shipping
From inside the pod, run a command like:

aws s3 ls s3://your-bucket-name
aws s3 cp s3://your-bucket-name/path/file.txt -

Confirm you can read, not write. Try an aws s3 rm and watch it fail.

5. Lock it down
Prevent privilege creep by auditing IAM policies monthly. Tag roles with purpose and owner. Limit access to assume roles on a need-to-use basis.

Fast, secure, and minimal — just enough to get your app the data it needs without opening the door to an attacker.

Your cluster deserves that level of precision. If you’re ready to see Kubernetes Ingress and AWS S3 read-only roles working together without the duct tape, hoop.dev can get you there in minutes.

Get started

See hoop.dev in action

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

Get a demoMore posts