Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Computing minimum permissions from resource usage #722

Closed
melbourne2991 opened this issue Apr 15, 2019 · 1 comment
Closed

Computing minimum permissions from resource usage #722

melbourne2991 opened this issue Apr 15, 2019 · 1 comment
Assignees
Labels
kind/enhancement Improvements or new features resolution/wont-fix This issue won't be fixed
Milestone

Comments

@melbourne2991
Copy link

Currently pulumi defaults to assigning broad access policies to compute resources

arn:aws:iam::aws:policy/AWSLambdaFullAccess,arn:aws:iam::aws:policy/AmazonEC2ContainerServiceFullAccess

If you want to use more restrictive policies - you can, however my understanding is you have to define them yourself.

Ideally pulumi would default to bare minimum, restrictive policies and deduce what additional policies/permissions are required based on how resources are used. Eg. a put call from within a function to a table would result in a policy being assigned to the function that allows puts to that table.

While this should be possible with inline lambda callbacks, I assume it would not work with Tasks and other external resources (because pulumi has no visibility over the references/resource usage) - so not sure what the solution here would be exactly.

@lukehoban
Copy link
Member

I'd love to do something like this.

In the past, we've discussed doing this at the pulumi-aws layer.

We could have serializeFunction in the core SDK return a list of captured resources (it already computes this for other reasons - just doesn't return it). Then the code in pulumi-aws that constructs a Lambda from a serialized function could use that list of resources to compute a minimum grant of permissions.

The biggest challenge would be enumerating the map from AWS resources to IAM permissions. This map is also likely evolving over time, and is not schematized anywhere.

This could be the default, with the current broad rights an opt-in (breaking change), or vice-versa (not a breaking change, but less useful).

@CyrusNajmabadi CyrusNajmabadi removed their assignment Jan 8, 2020
@lukehoban lukehoban added the kind/enhancement Improvements or new features label Jul 24, 2023
@mjeffryes mjeffryes added the resolution/wont-fix This issue won't be fixed label Jun 28, 2024
@mjeffryes mjeffryes self-assigned this Jun 29, 2024
@mjeffryes mjeffryes added this to the 0.107 milestone Jul 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Improvements or new features resolution/wont-fix This issue won't be fixed
Projects
None yet
Development

No branches or pull requests

4 participants