Comment by inkyoto

Per-resource IAM policy generation alone is not even half good enough. Most AWS services have complex IAM policy requirements that are unique to a specific AWS service or product, and within each there is typically a subset of policies being necessary (less frequently, the entire lot of them) – depending on which parts of the service/product are used, e.g. take a look at https://docs.aws.amazon.com/appflow/latest/userguide/securit...

Oftentimes, resource policies require condition or context keys to be supplied, e.g. https://docs.aws.amazon.com/glue/latest/dg/using-identity-ba...

Or a S3 cross-account replication policy that requires a specific condition to be able to decrypt and re-encrypt the data in the S3 bucket. KMS policies, in general, are notorius for mandating conditions and context keys – at once.

Cross-account IAM resource policies are even more complex, as they require policies to be configured in both accounts, and the policy is different in each of accounts; take Glue as a simpler example: https://docs.aws.amazon.com/glue/latest/dg/cross-account-acc... Such knowledge can't be [easily] derived from parsing and analysing a terraform codebase alone.

Without maintaining a comprehensive repository of AWS services and IAM policy generation rules specific to each of the AWS services that can support a specific permutation of product features used in a project, I fail to see how this product is useful or what it can do beyond trivial «grant the service instance ABC access to the service DEF by using DEF's ARN». Which is… frankly not very useful on its own.