Why do we keep using "*" and then complain about it? Is IAM so challenging?
So you might need many iterations of trial and error possibly involving different teams (dev, sec, ops, etc...) just to figure out the minimum pivileges needed for something.
As a concrete example, check the docs for boto3's upload_file method: https://boto3.amazonaws.com/v1/documentation/api/latest/refe...
UploadFile is not a S3 API action, so there's no IAM policy for that. It's up to you to search in the docs and in the internet which S3 APIs upload_files uses under the hood and how to properly design a policy for those.
As a possible solution, here's how AWS CDK does things:
> a = SomeResource()
> b = OtherResource()
> a.grant_read(b)
Resources auto generate IAM policies from high level constructs, which leaves much less room for human error.
From my experience I would say that there may be different factors:
- Every developer is an exception
- IAM is challenging to scale
- Lazy IT Teams?
- Visibility of access controls are poor
Some useful references:
- https://sysdig.com/blog/identity-access-management-difficult...
- https://www.effectiveiam.com/why-aws-iam-is-so-hard-to-use
- https://aws.amazon.com/blogs/security/iam-access-analyzer-ma...
Add to that a cloud migration severely underestimated that involves refactoring of n legacy processes (and possible team reorganization), a "brilliant" idea of mapping AD roles and nonsensical forests into <insert propietary cloud IAM solution>, a new CISO coming in following the mantra of least privilege without taking the time to understand (and eventually help redesign) current operations, and urgent deadlines to meet/emergencies to manage/general unwillingness to change standard operating procedures for the new environments (trying to fit everything in the custom servicenow workflows that was designed years ago)... the result is either everyone gets its own tailored set of overpermissions, or broad wildcard roles that for some strange reason fit <insert compliance framework>.