At Amino, we were constantly bumping up against some AWS resource limits when trying to build out least-access policies for AWS users. We wrote Wonk to help us with this. It combines multiple policies into "policy sets" that are the exact equivalent, but fewer in number and like (much) smaller.
For instance, if one policy on a user grants access to Service:GetThis and Service:GetThat, and another policy grants access to Service:Get, then Wonk only includes Service:Get in the final results.
While Wonk is still a young project, we've been using it in production for a while now. Hope this can help someone else!
One of the perpetual frustrations with AWS is their relentless focus on adding services rather than fixing more fundamental limitations of usability of their entire service.
So in some ways, it's a shame this is even necessary, but it really is. Really good of you to release this.
I agree. Here's my pet peeve: say you want to require users to log into the AWS console using MFA. You look all over the place for the magic "[ ] Require MFA" checkbox. Nope! Instead, the official docs at https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_p... show you how to create an IAM policy that will "deny all" except for some MFA-related stuff unless the use has logged in with MFA. Rather than add the checkbox, they require you to manually set a policy to do it. (Bonus points: the policy as-is doesn't let the user change their password unless they've logged in with MFA, but that's the first thing a brand new user account has to do. Then they can't change their password without MFA, and they can't configure MFA without changing their password. You can update the policy to allow password changes or you can not enforce "user much change password at first login" as a workaround.)
I generally like AWS a lot, but there are surely plenty of dark corners in the service. Wonk let us shine some light into a couple of them.
To draft new IAM policies I've been using the policy sentry tool Salesforce has in their public github and it's definitely been helpful. I'll for sure check out Wonk and see if it's good for my use cases.
You're welcome! It's currently aware of Condition (and other) constraints:
> Note: actions are always grouped by similar principals, resources, conditions, etc. If two statements have different conditions, say, they are processed separately.
That is, if a rule has constraints, it's grouped with other rules that have the exact same constraints. As of today, it doesn't do anything to smartly work across the various groups. Deny statements work the same way: they're grouped with other Deny statements.
[+] [-] kstrauser|4 years ago|reply
For instance, if one policy on a user grants access to Service:GetThis and Service:GetThat, and another policy grants access to Service:Get, then Wonk only includes Service:Get in the final results.
While Wonk is still a young project, we've been using it in production for a while now. Hope this can help someone else!
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] samstave|4 years ago|reply
I have never not had a resource limit increase request denied.
You can do this as granular as you like...
[+] [-] Hallucinaut|4 years ago|reply
So in some ways, it's a shame this is even necessary, but it really is. Really good of you to release this.
[+] [-] kstrauser|4 years ago|reply
I generally like AWS a lot, but there are surely plenty of dark corners in the service. Wonk let us shine some light into a couple of them.
[+] [-] AceyMan|4 years ago|reply
[+] [-] ncc-erik|4 years ago|reply
Do you currently, or plan to, handle Condition constraints? Also, how does wonk handle combinations with statements that have the Deny effect?
[+] [-] kstrauser|4 years ago|reply
> Note: actions are always grouped by similar principals, resources, conditions, etc. If two statements have different conditions, say, they are processed separately.
That is, if a rule has constraints, it's grouped with other rules that have the exact same constraints. As of today, it doesn't do anything to smartly work across the various groups. Deny statements work the same way: they're grouped with other Deny statements.