🎉 We are launching a new weekly show: Hot off the Cloud

🎉 We are launching a new weekly show

AWS Security: Stephen Kuenzli and Andreas Wittig on IAM

Andreas Wittig – 15 Feb 2022

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.

AWS Security

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.


Looking for a new challenge?

  • tecRacer

    Cloud Consultant • AWS Migrations

    tecRacer • Premier AWS Consulting Partner • Germany, Austria, Portugal, and Switzerland
    Assessment Transformation Change Management
  • DEMICON

    Senior Lead Full Stack Developer

    DEMICON • AWS Advanced Consulting Partner • Remote
    AWS JavaScript/TypeScript Angular React

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).

Become a cloudonaut supporter

Andreas Wittig

Andreas Wittig ( Email, Twitter, or LinkedIn )

We launched the cloudonaut blog in 2015. Since then, we have published 360 articles, 49 podcast episodes, and 48 videos. It's all free and means a lot of work in our spare time. We enjoy sharing our AWS knowledge with you.

Please support us

Have you learned something new by reading, listening, or watching our content? With your help, we can spend enough time to keep publishing great content in the future. Learn more

$
Amount must be a multriply of 5. E.g, 5, 10, 15.

Thanks to Alan Leech, Alex DeBrie, ANTHONY RAITI, Christopher Hipwell, Jaap-Jan Frans, Jason Yorty, Jeff Finley, Jens Gehring, jhoadley, Johannes Grumböck, Johannes Konings, John Culkin, Jonas Mellquist, Juraj Martinka, Kamil Oboril, Ken Snyder, Markus Ellers, Ross Mohan, Ross Mohan, sam onaga, Satyendra Sharma, Shawn Tolidano, Simon Devlin, Thorsten Hoeger, Todd Valentine, Victor Grenu, and all anonymous supporters for your help! We also want to thank all supporters who purchased a cloudonaut t-shirt.