An artifact bucket policy should name one writer (the CI role), a short list of readers (deploy roles), require encrypted connections, and allow no public access. Add logging and versioning, and keep ACLs off. The rest is housekeeping you can check in ten minutes.
Why artifacts need their own bucket
Build output is the thing you ship. If someone can overwrite it, they can ship their code under your name. If someone can read it, they may find embedded configuration or unreleased code. A bucket shared with logs, backups and website assets makes it hard to give each group the right access, so start with a bucket used only for artifacts.
The checklist
- Block all public access at the account and bucket level.
- Keep ACLs disabled with Object Ownership set to bucket owner enforced. AWS says this is the default for new buckets, and that access is then governed by policies.
- Give write access (PutObject) to the CI role only, on the artifact prefix.
- Give read access (GetObject) to named deploy roles, not to the whole account.
- Deny requests that are not over TLS.
- Turn on versioning, and consider Object Lock for release prefixes.
- Enable server access logging and CloudTrail data events for the bucket.
- Review with an access analysis tool for external or public access.
Writers and readers
Prefer role ARNs in the Principal element over account wide grants. AWS's least privilege advice is to grant only the permissions required, on specific resources. For a CI role, that is PutObject on one prefix, plus list permission if the tooling needs it. Do not grant delete permissions to the CI role unless a cleanup job truly needs them, and keep that job separate.
Use IAM roles for applications and services that need bucket access, instead of storing long term keys. AWS notes long term credentials in an application or instance are not automatically rotated and can have a significant business impact if compromised.
Requiring TLS
AWS recommends allowing only encrypted connections by using the aws:SecureTransport condition in bucket policies. A deny statement looks like this:
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": ["arn:aws:s3:::my-artifacts", "arn:aws:s3:::my-artifacts/*"],
"Condition": { "Bool": { "aws:SecureTransport": "false" } }
}
A deny for a principal of star is fine here, since it only removes access. AWS also suggests alarms on events with no TLS version to spot plain HTTP attempts. A managed Config rule exists to check this setting continuously.
Encryption at rest
AWS states all S3 buckets have encryption configured by default and new objects are encrypted at rest, with S3 managed keys as the default. If you need key level audit or separation, choose KMS keys at the bucket level. Also note that since April 2026 AWS disables SSE-C for new general purpose buckets, so do not design around customer provided keys unless you enable them on purpose.
Detective controls
Write down which alerts you would want: a change to the bucket policy or public access settings, a delete of a locked object, a read by an unknown role. AWS documents CloudWatch alarms for bucket policy changes as an example. Without alerts, your policy is a snapshot, not a control.
Quick check
Should the CI role be able to delete artifacts?
Usually not. Grant write to one prefix and handle cleanup with a separate, narrow job.
Is a deny for principal star dangerous?
Not for a TLS only deny. A deny statement removes access, so it cannot make the bucket public.
Safeguard does not manage your cloud accounts. It scans your code and dependencies, applies pull request policies and gates, and automates compliance evidence. Free scan: gold.safeguard.sh/scan.
Sources
- Amazon S3 User Guide: Security best practices
- Amazon S3 User Guide: Blocking public access to your Amazon S3 storage
Last reviewed: 19 October 2026.
