This message was deleted.

Practically speaking, I have found that you really need to grant full admin in AWS to any IaC because you need full admin to create IAM resources, and things like Lambdas require IAM roles.

Once your project is deployed, has been in use for a while, and is stable, you can then use IAM Access Advisor to see what permissions your projects actually used (assuming you use a single role to deploy your entire project). You can then update your role to be limited to those permissions. Also, you can often split the admin-only aspects of your deployment from the "normal" IaC. Setting up the base IAM stuff, including OIDC for GH/Pulumi, is a good example of work that should be separate from, and use a different role to, your normal IaC work.

Yeah, I split admin deploy vs App deploy with OIDC so that app devs aren't bothered with extra stuff in the repo. And full infra repo is accessible only by a few members. I am try to avoid full admin for CI as much as possible. One of the ideas was to force manual deployment of IAM stuff.

OIDC? I get a lot of confidence from the GH->AWS OIDC integration.

This is our setup: • main infra repo (many apps) -> GH -> AWS OIDC -> full role -> pulumi Up • app repo -> main infra/app -> GH -> AWS OIDC -> app role -> pulumi Up