AWS Security: Stephen Kuenzli and Andreas Wittig on IAM

Stephen Kuenzli and I lead several cloud migration projects. In this conversation, we shared our learnings focusing on AWS security and IAM (Identity and Access Management). The result is advice and inspiration that will help you in your daily work. Our conversation is available as a video or podcast episode. In the following, you will also find a summary of our discussion.

As Michael is on parental leave, I invited Stephen to the cloudonaut podcast. Listen to our conversation on AWS security and IAM. Stephen has written a book for engineers who design, develop, and review AWS IAM security policies in their daily work: Effective IAM for Amazon Web Services. Besides that, Stephen is the founder of k9 Security with the mission to help organizations use the Cloud to improve security and manage risks to the organization and its customers.

Do you prefer listening to a podcast episode over reading a blog post? Here you go!

For the first time, we recorded audio and video as well. Therefore, the podcast is available on YouTube as well.

You will find the distilled advice from my conversation with Stephen in the following.

Use AWS accounts to isolate workloads

When multiple workloads are running in the same AWS account, writing IAM policies to separate those workloads from each other gets tricky. In theory, IAM supports ABAC (attribute-based access control), but although AWS made some progress in that area, not all resources and actions are supported. Also, implementing ABAC adds a lot of complexity. Therefore, our advice is to use multiple AWS accounts to isolate workloads from each other. For example, to separate test and production workloads. Or to provide a sandbox environment for developers.

We also learned that it could be tricky to get too granular when using AWS accounts to isolate workloads. Managing hundreds or thousands of AWS accounts becomes problematic, especially when network connectivity between workloads is required. So, as is so often the case, it’s all about getting the balance right.

Do not use AWS managed policies

AWS provides IAM policies that you can use out-of-the-box. However, the AWS-managed policies are imprecise. First, the policies do not include resource-based restrictions. Second, the policies typically grant access to more actions than needed. For example, the ReadOnly policy is often used by 3rd party tools to access information about your infrastructure. Did you know that the ReadOnly policy not only grants access to list all your EC2 instances? It also gives access to read all the data stored in your S3 buckets?

Another problem with AWS-managed policies: they are subject to change. And you might not notice when AWS adds another service or action.

To reduce the blast radius of security incidents, you should implement the least privilege principle for machines (IAM roles) and humans (IAM users, groups, and roles). To do so, create your own IAM policies or use AWS-managed policies very carefully.

How to create an IAM policy?

But how to come up with an IAM policy? Stephen and I want to share some tips and tricks for different scenarios.

1. Writing an IAM policy for a 3rd party application running on EC2, Fargate, or Lambda.
2. Check documentation for IAM policies. When available, review whether the policy follows the least privilege principle (validate actions, resources, and conditions).
3. Use CloudTrail - or even better Client Side Monitoring (CSM) - to get information about the actions and resources accessed by the application.
4. When working with open-source, search for AWS SDK usage within the code.
5. Writing an IAM policy for an application developed in-house.
6. Ask a developer for help to search the code for AWS API calls.
7. Search for AWS SDK usage within the code yourself.
8. Writing an IAM policy for humans (e.g., to grant developers access to AWS).
9. Restrict as little as possible (e.g., deny deleting databases or backups). Use an allowlist of services (e.g., SOC compliant).
10. Make sure you are not slowing down engineers, educate about security, and use monitoring instead.

Consider KMS key policies to control access

Consider using KMS keys with key policies to restrict access to sensitive data. Think about encryption as a second layer of authorization. But be warned using customer-managed keys for encryption adds complexity. For example, you need to ensure that no one deletes the keys. Otherwise, your data will be lost, including the backups which use the same key for encryption.

Build reusable components to scale security

It is not realistic to expect every engineer to become an IAM expert. Therefore, build reusable components to generate IAM policies. For example, application X needs read access on bucket Y and write access on table Z. Alternatively, built-in IAM policies into your Infrastructure as Code components (see CDK or cfn-modules).