|
|
|
|
|
by x_foo_x
3381 days ago
|
|
AWS policy descriptors are certainly robust enough to handle something like this. These frameworks are built for hackathon type projects where you are just using a personal AWS account and you don't care about fiddling with permissions. Try getting access to an Administrator user/role at a big company. To back up my first point, the framework owner could easily instruct users to set up a temporary user/role that creates the initial function roles/policies as one-time setup. Then a user/role with only the service-level permissions (Lambda etc.) could manage all the actual resources. The devs who build these frameworks want them to be super simple to use, otherwise they won't retain users! |
|
And to your first point, it's not just being super simple though; fundamentally you have to have that admin access to be able to deploy initially.
After that, sure, provided you make no changes to the policies, the framework could theoretically diff the policies with just the iam:Get* actions applied, ensure they're the same, and deploy without touching it. But you get into weird situations where you decide "oh, this function now needs access to Dynamo, so let me modify the policy for the role the lambda is executing under", and now you have to have admin credentials again. Any new resources in AWS you want access to require you to have the iam:PutRolePolicy action, which, given you already created it and attached it, is again equivalent to admin rights, and the ability to do anything.