Since the beginning, writing IAM policies with the minimum necessary permissions has been hard. Some services don’t have resource-level permissions (you have to grant to
*), but then later they do. When a service has resource-level permissions, it may only be for some of its permissions (the rest still need
*). Some services have their own Condition Operators (separate from the global ones) that may or may not help you tighten control. Et cetera. The details are documented differently for each service and it’s a lot of hunting and testing to try to put together a tight policy.
Amazon made it easier! There’s new magic in the IAM UI to help you create policies. It has some limitations, but it’s a big improvement. Here are some of the things it can do that I used to have to do myself:
- Knows which S3 permissions require the resource list to include a bucket name and which require the bucket name and an object path.
- Tries to group permissions and resources into statements when it results in equivalent access (but sometimes ends up granting extra access, see below).
- Knows when a service doesn’t support resource-level permissions.
- Knows about the Condition Operators specific to each service (not just the global ones).
There are some limitations:
- Doesn’t deduplicate. If you add permissions it doesn’t go back and put them into existing statements, it just adds new statements that may duplicate parts of old ones.
- Only generates JSON, so if you’re writing a YAML CloudFormation template you should translate.
- Seems to have limited form validation on Condition Operators. You can put in strings that will never match because the API calls for that service can’t contain what you entered (making the statement a no-op).
- Can end up grouping permissions in a way that makes some resource restrictions meaningless and grants more access than might be expected.
- Sometimes it messes up the syntax. Seems to happen if you don’t put exactly what it expects into the forms.
So there are a few problems, but this is still way better than it was before! My plan is to use the visual editor to write policies, then go through and touch it up afterward. Based on what I’ve seen so far, this cuts the time it takes me to develop policies by about 30%.
If this was helpful and you want to save time by getting reviews for the latest tooling for Cloud DevOps in your inbox, subscribe here.