As Andrew Carnegie put it, “Anything in life worth having is worth working for.” I’m going to take some liberties here and say that since security in your AWS account is worth having, it’s definitely worth working for.
IAM permissions are incredibly important to the security of your AWS resources. However, creating IAM policies is a difficult skill to master. Security, by nature, is difficult. There is no “easy button” (if you happen to find one, let me know!). However, with the right resources, you will be on track toward a more secure AWS account.
In September of last year, my team member (Justin Iravani) wrote about how IAM Permissions Can Be Tricky and included some helpful tips for granting least privilege. A few months ago, I wrote a blog post on using the IAM Policy Visual Editor.
Building on previous blog posts, this post is a collection of useful resources that can help you build effective IAM security policies. These resources are meant to help you get a jumpstart on creating your policies, but as mentioned above, it will take time to get your policies just right—and even after that, they will probably need to be tweaked/updated every so often.
IAM Policy Reference
The IAM Policy Reference is your go-to documentation for detail about IAM. The policy reference was recently updated with tables to provide a clearer view of what actions are available for a particular service, which resources those actions can be performed on, resource types, and more, to help you scope your permissions. This is a great resource for the most up-to-date information on the latest AWS services and IAM actions.
AWS Services That Work With IAM
AWS provides a guide called AWS Services That Work With IAM that provides a list of all AWS services and whether or not they work with Resource-Level (delegated by IAM policies) and Resource-Based permissions (delegated by the resource). This allows you to quickly evaluate if you need to spend time creating a restricted policy for a specific service or resource.
For example, in the table below, you can see (as indicated by the red arrows) that you don’t need to spend time narrowing down permissions to CloudWatch. Why? Because it does not support Resource-Level permissions. However, for CloudWatch Logs you’ll want to scope permissions down to specific resources.
AWS ARNs and AWS Service Namespaces
Another useful resource is the AWS ARNs and AWS Service Namespaces page. This page shows every ARN pattern possible for specific services. Refer to this page to ensure your ARN patterns are correct for the services you are using (not all ARNs follow the same pattern).
Here’s an example that has tripped me up in the past:
Most resources use a forward slash (“/”) when delimiting a resource type and name (e.g., arn:aws:iam::account-id:role/your-role-name). However other services, like Lambda, use a colon (“:”) when delimiting a resource type and name (e.g., arn:aws:lambda:region:account-id:function:function-name). This subtle difference can make or break your IAM policies.
Visual Editor
As I posted about a few months ago, the Visual Editor is to help you create policies. It can be found in the AWS Console when you’re creating managed or inline policies. The Visual Editor can help you more easily build IAM policies without worrying about writing JSON. It’s another way to quickly help you determine which IAM actions support Resource-Level permissions and which ones require Resource: “*”.
This may seem like a simple answer, but it’s a very powerful one. Knowing how to search for and where to find examples of IAM policies can help you quickly jumpstart your policy writing process. I often find myself googling for “Limiting Access to AWS X Service” as my search term. This can bring up AWS documentation pages for a specific service that may have good examples of IAM policies that limit user access—for examples, Amazon ECS IAM Policy Examples, or Controlling Access to Amazon EC2 Resources. However, before you use a sample policy, make sure to modify it for your use case and ensure you’re following security best practices!
Conclusion
Writing secure IAM policies can be difficult and a bit time consuming, but with good resources and references you can quickly speed up the process of writing effective policies. By using the resources mentioned above, you should be well on track to improving the security posture of your AWS account. Remember, security in your AWS account is worth working for.
