I find it hard to do a sensible lockdown of GitHub Actions based on repositories using idp, because even though I am using a tool like https://github.com/iann0036/iamlive it means we have to bring up every stack as a admin user in AWS or just keep running the Action over and over again, basically brute forcing it. I don’t want to use

action:*

, but I also can’t help every single developer with what ever minor action they need added to their runner (it also pollutes our Pulumi Service history with a bunch of failures). I know I have asked this before, but I would love to get some input from real world experience. Do people actually list out every specific action in each GitHub Action, or do they use wildcards?

honestly, you’re going to be constantly playing whack-a-mole if you’re trying to chase Pulumi code -> IAM perms. I generally just give out admin perms Part of the reason for this is that every single modification of code is going to need a permission update which is I think what you’re seeing. A pretty common pattern I’ve seen is using an admin role in development, using iamlive to scope the perms and then for production, locking down the iam role

That makes a lot of sense, I agree. One middle ground is perhaps to assign more “freely” like `rds:*`if a repo needs rds or

s3:*

if it needs S3 access. After all assuming GitHub Actions (enterprise) are secure, main branch protected and we are using idp for actions it should be fairly unlikely that someone manages to do a lot of harm to our infrastructure.