Why Pipelines Need AWS S3 Read-Only Roles
CI/CD pipelines often need to pull build artifacts, configs, or static data from S3 buckets. Direct credentials inside a repo are a security risk. Temporary credentials through IAM roles are safer and meet compliance standards. A read-only role keeps the pipeline from writing or deleting data in S3, reducing the blast radius if credentials are leaked.
Core AWS IAM Setup
- Create an IAM role with an S3 read-only policy (AWS managed policy:
AmazonS3ReadOnlyAccessor a custom one allowings3:GetObjectands3:ListBucket). - Scope the resource ARNs to the exact buckets and prefixes you need.
- Attach the role to the pipeline’s execution environment, such as an AWS CodePipeline action or a build job in CodeBuild.
- If using external pipeline runners like GitHub Actions or GitLab CI, configure IAM role assumption via OIDC to avoid static keys.
Least Privilege Matters
Broad read permissions on all buckets are faster to configure but dangerous. Scope your policies to:
- The specific bucket (e.g.,
"arn:aws:s3:::my-artifacts-bucket") - Key prefixes that match the data set (
"arn:aws:s3:::my-artifacts-bucket/builds/*")
Integration with Common Pipelines
- AWS CodePipeline / CodeBuild: Assign the IAM role directly to the service role.
- GitHub Actions: Use
aws-actions/configure-aws-credentialswith role assumption via OIDC. - GitLab CI/CD: Use AWS CLI and environment variables from temporary credentials retrieved at job start.
Testing Access
Before running the full pipeline, validate S3 permissions with:
aws s3 ls s3://bucket-name --profile assumed-role
If this fails, review the IAM trust policy and the S3 bucket policy. Both must grant read access.
Security Checks
- Rotate any fallback credentials.
- Audit CloudTrail logs for unintended accesses.
- Remove unused roles.
Tight, read-only roles keep pipelines safe and fast. They also simplify audits and pass security reviews without drama. See how you can set up secure pipeline access in minutes at hoop.dev and watch it run live.