[Eridrus]

IAM is horrific, but I feel like it's not really the application-specific stuff that is annoying for me, it's the stuff that AWS wants configured for AWS features to work and the fact that the error messages when you get it wrong are useless at pinpointing your mistake, when you do not know that access is mediated by IAM.

Just as an example, I setup a containerized app on Fargate with a custom role, and the need to configure the ability for ecs to assume the role, read from ecr, write to cloudwatch, create channels for debugging was super annoying.

Comparatively, having a policy for it to read from an s3 bucket with my data was trivial.

[teaearlgraycold]

I just set up an S3 bucket - probably the most common use case for IAM policies. My policy file was invalid in a way that AWS never warned me about and looked good to my untrained eyes. After a few hours of debugging GPT-4 was able to explain I needed to break up my rules into bucket-level and key-level sections. Afterwards the 403 errors went away.

Just sharing my story. IAM sucks and GPT-4 is a good backup for configuring it.

[Eridrus]

I guess I did not try to deal with anything key related, so that's probably why it was simpler for me.

I do agree that everything about it is horrific, though I'd be surprised and impressed if an LLM were able to generate your key setup from scratch.

[lasermike026]

You get used to it.

[Eridrus]

Sure, you can get used to anything, but it still sucks and is worth trying to improve the situation on.