The bucket was there, but no one could read it.

Locking down AWS S3 from inside a Kubernetes cluster is simple to do the wrong way. Wide-open IAM roles are fast to set up, but they create risk you cannot ignore. Granular, read-only access to S3 buckets is the safer path, and with the right configuration, pods can reach AWS without leaking power they do not need.

Start by creating an IAM policy that allows only the s3:GetObject action for the required bucket. Avoid s3:* or wildcard ARNs. Precision matters. Attach this policy to a role you will use exclusively for Kubernetes workloads that need S3 read access.

If you run on EKS, use IAM Roles for Service Accounts (IRSA). Create an OIDC identity provider for your cluster, then bind your IAM role to a Kubernetes service account. This ensures that only pods using this service account can assume that IAM role. No sidecar, no node-wide keys. Direct, scoped trust between AWS and Kubernetes.

In your pod spec, reference the service account with the bound IAM role. Keep the AWS SDK configuration lean; let IRSA handle the credentials. This passes temporary access tokens straight into the pod without storing secrets in your cluster.

Test by reading a single object from the bucket. If the pod cannot write or list outside its scope, the policy is working. Read-only means read-only.

This setup scales cleanly across namespaces and workloads. One bucket, one role, one service account. More buckets mean more roles. Each access pattern stays isolated.

If you want to see this pattern in action without the manual setup, Hoop.dev connects Kubernetes workloads to AWS S3 with locked-down, read-only roles in minutes. No guesswork, no drift, ready to go live.