AWS Managed IAM Policies
Understanding AWS Managed IAM Policies
AWS Managed IAM Policies are an interesting and powerful construct in the AWS cloud. Essentially it’s a library of IAM policies written and maintained by the AWS team that you can use (but not change) in your accounts.
As far as we can tell, the main benefits of using AWS Managed IAM policies are the following:
- Greater efficiency, by reusing existing policies written by AWS itself instead of writing your own from scratch.
- Greater readability of your policies, since experienced AWS admins in theory are already familiar with the AWS Managed IAM Policies.
- Future proofing, since AWS keeps policies up-to-date with statements as new operations and services are created in the dynamic landscape of the AWS APIs. For example, using the SecurityAudit policy for a security tool or auditor will ensure new privileges are added automatically by AWS as they are launched.
These benefits are not dissimilar to those brought about by using good third-party libraries in your code. However, they also carry some significant risks which we’ll explore in the next section.
In this post we will show some graphs generated with Python code using boto3, Jupyter notebooks, Pandas and matplotlib to perform some simple data analysis on the historical record of AWS Managed IAM Policy versions. The same data can be obtained in any SDK using the ListPolicies and ListPolicyVersions API operations, or in this Github repository by Victor Grenu. The data displayed here is based on the data as observed on November 2nd, 2020.
Firstly, AWS pushes changes to these policies fairly often. Let’s take a look at a graph that shows how frequently new policy versions are published:
Notice that, after the initial load in Q1 of 2015, there is a clear growth trend in the number of policy versions published over time.
Also, changes tend to occur more frequently on the 4th quarter of each year. This immediately reminded us of the flurry of new releases AWS has each year just before and at re:Invent, their global conference held historically in late November. Breaking down the number of new policy versions per month seems to support this, as November has a clear lead:
Having said that, most policies don’t have a lot of versions. Over 88% of policies have 5 or fewer versions, for example. This concentration becomes even more clear on this histogram:
For reference, these are the top 19 policies by number of versions on the date this was written:
The Drawbacks
Unfortunately, even though all policy versions are shown by the APIs, users cannot choose which they want to use. As soon as AWS publishes a new version and defines it as the new default, it is immediately applied to all accounts. To make things worse, as Richard H. Boyd put it, “any deployment will be outside working hours for ~2/3 of the world”.
This is far from ideal, as it makes change management of any kind on the customer side essentially impossible. Changes by AWS can happen at any time, and currently the only way to opt-out is to not use AWS Managed IAM Policies in the first place.
This means that any breaking change done by AWS on an AWS Managed IAM Policy has the potential to impact any of your accounts and systems that happen to use them. And though we can’t say that this happens frequently, it does happen:
Also, AWS apparently has in the past accidentally published and then deleted policies that were meant to be internal only:
There are also no guidelines, to our knowledge, that limits the sort of changes AWS can do to a policy. Removing or adding conditions to granted privileges can break environments that rely on them causing downtime or errors, and adding new privileges can create new security concerns.
Recommendations
If you are a typical AWS customer, avoid using an AWS Managed IAM policies for any sort of automated workloads. Either write your own from scratch or copy the contents of the best version of a managed policy, and this way you prevent any issues caused by updates published by AWS.
Two exceptions to this general rule that come to mind are when the AWS updates are more of a feature than a bug:
- A third party using SecurityAudit for a cross-account access role. The added work of asking all SaaS customers to update the role on each account might tip the scales in favor of using the AWS Managed IAM Policy… but then again keep in mind AWS takes it sweet time adding new services to it.
- When assigning role policies to human beings in AWS SSO, particularly to teams like IT and Audit, if the intended use of the managed policy is a good fit and the users are trusted within reason.
Finally, there are many things that AWS should do to improve matters here. Our wishlist for this would be to treat AWS Managed IAM Policy version releases the same way that RDS treats database engine upgrades:
- Allow customers to have control over whether updates are done automatically or manually;
- Allow customers to define a window when automatic updates are applied;
- Separate breaking changes (privileges were removed) from non-breaking changes (privileges were added) and allow customers to automate only the latter, as RDS does with the separation of minor and major version changes.
Don’t hesitate to get in touch if you want to learn more about how Tenchi Security can help your organization optimize its cloud security access control and overall posture.
Research and blog post by Alexandre Sieira.
