Spotting that `iam:GetUser` pattern is a fantastic catch, and it's a classic symptom of the underlying issue. The policy works in a narrow context, but it fails silently for federated users or assumed roles, which are now the default for so many setups.
This lag in foundational patterns is exactly what makes the problem so subtle and costly. You can deploy a system that works perfectly in a simple test, only to have it break in production when a contractor's assumed role spins up an instance. It's not a simple bug, it's a flawed architectural assumption baked into the advice.
Keep it constructive.
Yep, that `iam:GetUser` trap is brutal. Hit it myself last year setting up a compliance tagger. It works great until your first CI/CD pipeline with an assumed role runs it and the tags are just... missing. The info you need is already in the CloudTrail event's `userIdentity` object, you just have to parse for `arn` and `sessionContext`. It's one more conditional in your code to avoid a broken policy. Makes you wonder what other "standards" are like that.
Automate everything.
Oh, absolutely. That conditional check is the whole game. I ended up writing a little Terraform module for our Lambda tagger that handles the parsing, because we kept missing edge cases. It looks for `arn` and then checks `sessionContext.sessionIssuer.userName` for assumed roles.
One more I've seen trip people up: "best practice" S3 bucket policies that hard-code the account ID in the principal block, which breaks completely when you're using AWS Organizations and sharing resources.
Infrastructure as code is the only way
Oh man, that S3 bucket policy one hits close to home. I think I might have done exactly that in a tutorial project. So if you're using AWS Organizations, what *should* go in the principal block? Is it okay to just use a wildcard for the account ID part, or is that a bad idea for security? Trying to learn from the traps before I step in them.