03SECURITY & STORAGE · PERSONAL LAB
Secure artifact storage on AWS.
A private S3 release bucket with scoped uploads, KMS encryption, audit events, and resources imported into Terraform.
IAM roleScoped upload access
Private artifactsAmazon S3
AWS KMSEncryption key
CloudTrail data eventsreleases/*
Completed personal learning lab. The original verification was recorded during the lab; raw command output and a public source repository are not attached here yet.
The problem.
A CI upload role should be able to publish build artifacts without receiving broad access to the whole storage account. I practiced enforcing that boundary in more than one layer.
The approach.
- Keep the bucket private, disable ACLs with bucket-owner-enforced ownership, and enable versioning.
- Scope the CI role’s upload permissions to the release prefix and deny requests without TLS.
- Use a customer-managed KMS key and record relevant S3 data events in CloudTrail.
- Import the existing resources into Terraform and reconcile configuration with the actual resources.
Decisions that mattered.
Access to a prefix
Grant the upload action only where release artifacts belong. Avoid making a CI identity a general-purpose S3 administrator.
Encryption has its own permissions
S3 access and KMS access are separate decisions. The key policy must support the intended upload path without granting unrelated key operations.
Bring the lab under code
Importing resources is only the first step. Compare the Terraform configuration with the existing state until the plan no longer proposes unintended changes.
Evidence & scope.
The lab record reports a no-change Terraform plan after import, with bucket versioning, encryption, and upload-role boundaries configured. Raw verification artifacts are not embedded in this site; no live storage status is implied.
What I took away.
Least privilege is a set of boundaries to verify, not a single policy to paste into the console.
UP NEXT / 01