Things you need to know before using AWS-managed IAM policies

For many AWS users, utilising the rich Identity and Access Management (IAM) features –  such as role-based access control, grouped users, cross-account roles, federate role – will be their first lesson in cloud security. And while the Principle of least privilege (PoLP) is well-known in the cloud engineering community, it’s easier to talk about, than to implement the principle in every aspect of cloud operation.

Recently I was invited by a friend, outside of work, to investigate a potential AWS account compromise incident. Some of the findings provide interesting advice for all AWS cloud practitioners.

Some AWS managed pre-defined IAM policies have a collection of actions that go beyond the scope of their names. For example, as shown below in Fig.1, “AmazonRDSFullAccess” contains privileges that one can describe all CloudWatch alarms and delete the specified alarms, with no restricted conditions.  This policy, from its name, sounds like just granting one with full access to all RDS resources. Apparently, the policy has allowed many more extras.

Another example is that “AmazonDynamoDBFullAccess” has granted someone to delete any Lambda functions. (Fig.2)

In some cases, the bundled privileges make tasks easier such as when decommissioning a collection of AWS assets involving multiple services. In others, they may deteriorate existing security methods if one applies the policy without knowing what it includes. If misused, the users of the AWS account may lose insights into critical operational events and result in a loss to the business. Similarly, the DynamoDB full access policy can be used to remove some Lambda functions that update the blacklisted IP addresses in a Web Application Firewall (WAF) rule.

Due to time restraints, we are not able to review every single similar policy here. So, our advice is simple:

1. Review any AWS managed policy by clicking the “JSON” tab above the policy body, and understand what privileges are included before you use it. Do not just take it for granted based on the policy’s name.
2. If the AWS managed policy does not meet your specific requirements on access control, then create your own custom policy.

There is no silver bullet in cloud security practice. No policies are “one-size-fits-all”. Before you use any predefined IAM policies, review them, review them and review them!