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!
Still, that doesn't fix the problem - it just defers it. For example, you can ask that the maximum number of managed policies on a user gets bumped from 10 to 20. That sounds like a lot, but if you want to use AWS-managed policies like to set up least-access privileges, you'll be using lots of them like "CloudWatchReadOnlyAccess" and "AmazonEC2ReadOnlyAccess". If you use more than 20 services, the problem's still going to bite you.
So.... I have run into this. You can require custom limit policies -- the caveat is that you as a company need to sign something that states that you take full responsibility for the allotment of the service based on you effectively controlling the quota.
This is done only through your rep, and with them talking to some internal teams....
Have a good relationship with your rep, and I have never gotten a "no" from Amazon....
Again, this is done through actually talking to them.
For example, I was spinning up thousands of instances for some things... and had to take full control of my limits with the agreement that I would pay for that which I spun regardless....
ALTHOUGH, once we had a dev accidentally check in secrets to github, on the 201st repo, which as our paid plan was 200 repos, it automatically mad #201 public - and within an hour we had hundreds of instances lit up in literally every AZ on the globe to mine for some german op....
It took us several hours to kill and close all that... but in the end, AWS just let go of the six-figure bill that would have ensued....
Your project is dope... I just want people to know that limits are soft-set.
The only limits that are hard set are the actual number of nodes available for anything in a given AZ/Region -- but their capacity is way beyond what it was a few years ago, so I don't see that as an issue any more.
However, again, your tool is dope.
---
EDIT: Also, I admit, I have not faced your issue, so aside from mine just being general advice, I do not mean to detract from your post or your release of effort.
:-)
(also, some of their best reps had moved to GCP a while ago - so I don't know who the current crop of 'best reps' is, else I would connect you.
Those are all good points, but it seems at least some of those limits are actually hard. You can have them increased but not removed. And it this case, that probably makes sense: if you could attach 10,000 policies to a user, it could be a pain in the neck for AWS to evaluate them at each action request.
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.
That's an option but it doesn't really scale across a lot of employees. There are many things I'd rather be doing than pestering new employees to enable MFA, when literally every other service we use that offers MFA has a checkbox to require it at the company level.
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.
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!