Automatically generate a list of required IAM policies (or similar for other providers)

[alex-e-leon]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

One challenge I'm finding I constantly run into is managing the IAM policies that I'm required to give pulumi in order for pulumi to create/update/remove all the resources it manages. When adding new resources I often find myself adding overly broad and permissive policies because otherwise I end up spending sometimes hours re-trying deployments and adding any required permissions up front. I also find myself rarely removing permissions out of fear of potentially breaking a deployment. In AWS especially this has bitten me as when adding extremely broad policies its easy to hit AWS's maximum policy length pretty quickly.

But it seems like pulumi should have all the required information to automatically generate a list of the policies it requires to deploy (infra's not my main area, so maybe its a hard problem, but either way it seems like it could be possible).

So my wishlist would be the following 2 features:

• When running pulumi:preview, check and print any missing policies/permissions that would cause the deployment to fail. Possibly behind a cli flag if necessary (though I feel like it wouldn't need to be)
• a seperate command which would print all policies/permissions required to create/update/delete all resources under management. This second request seems like it could be a much harder problem to solve, as some resources may have many different permission sets covering different kinds of updates. Maybe someone whos more versed in infra than I am can chime in with ideas or whether this would be feasible.

[justinvp]

Moving to the AWS provider repository.

[flostadler]

Hey @alex-e-leon, thanks a lot for this enhancement idea! While this would be a great quality of life improvement, I can see some challenges in this.

One challenge here would be analyzing what permissions a certain resource modification needs. Pulumi resources do not always cleanly translate to certain CRUD API calls in AWS. The creation/deletion of some resources (e.g. Security Groups) involves multiple conditional API requests. We'd need to form an inventory of all API calls in a resources CRUD life-cycle.

If we had that, we'd need some way to check this against a users current permissions. There's no way in AWS to retrieve a users current allowed permissions because IAM can get very complex (conditionals, deny blocks, resource based policies, permission boundaries, etc.). To check if the required operations are allowed we'd have to run simulations for all resources & actions pairings. This would be a pretty big corpus to test and take a long time (if I'd have to guess, minutes to hours depending on the size of the stack), but it would still not be accurate because it lacks support for SCPs or cross-account scenarios (see: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html#policies_policy-simulator-how-it-works).

I'm gonna bring this back to the team to do some brainstorming around this.

What you can do today

You mentioned that you're running into issues with max policy length and overly broad permissions.

To combat the max size limit, you could try splitting your permissions over multiple policies (roles can have 10 by default, up to 20 when filing for a quota increase). If you still run into issues after this, you could try other optimization techniques like leveraging wildcards (e.g. grant Describe*, Get*, List* instead of the individual permissions) to reduce the policy size.

To remove overly broad permissions with more confidence you could look into IAM Access Analyzer. It allows you to create policies based on your actual API usage: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html. But beware, it might not catch all possible API calls. For example it might miss the Delete calls if you've not run the deletes before.

[alex-e-leon]

@flostadler - Thanks for the thorough reply - I had a sneaky feeling that it wouldn't be as easy to implement as it seems like it could be on the surface, so appreciate the difficulty in potentially implementing some of this.

I personally think that even if pulumi is not able to check a users permissions, being able to generate a report of required permissions to perform an update could still be very useful, as it would still allow a manual audit of permissions, which would save having to update any broken permissions one by one in contexts where broad wildard permissions aren't allowed/preferred for security, which could save hours of re-trying. Obviously automating the auditing step as well would be a great addition though if eventually possible.

And thanks for the links and suggestions for managing IAM! I'll keep an eye on this space.