TCP #111: One standardized policy that killed 4 months of IAM escalations
How we went from recurring tickets to zero and made audit evidence boring again.
You can also read my newsletters from the Substack mobile app and be notified when a new issue is available
If three app teams share an S3 bucket in your AWS org, you probably have three different IAM policies and a hidden audit problem.
Here’s how we eliminated four months of IAM permission escalations with a single customer-managed policy in a single sprint.
THE PERMISSION CONFLICT THAT KEPT ESCALATING
Before the change, each team had written its own inline IAM policy for accessing the same shared S3 bucket.
Team A had scoped their policy by prefix. Team B had scoped by action, then added a wildcard when something broke in a hurry. Team C had copied Team B’s policy six months earlier, before Team B’s wildcard was added, and was missing two actions their pipeline now needed.
Every two to three weeks, one of the three teams would open a ticket. A deployment would fail. An access denied error would appear in CloudTrail. Someone would ping the platform team. The platform engineer on rotation would spend 45 minutes reading three different policy documents to figure out which one was the source of the conflict.
