Getting a grip on AWS Identity and Access Management with new open source tool AirIAM

AirIAm by Bridgecrew logo

Today we’re excited to introduce our second open source project, AirIAM, which uses infrastructure as code to manage AWS IAM. 🎉

AWS Identity and Access Management (IAM) is the AWS service that allows or denies every action in AWS for every service, server, or user. This service is inherently embedded into every deployment in the cloud on multiple levels, which requires a high level of abstraction and flexibility.

Mismanaged and misconfigured IAM can lead to many security risks such as account takeover or Bitcoin mining attacks using compromised privileges, data leakage using over-privileged roles, and many more.

As a Solution Architect at Bridgecrew, I see dozens of AWS accounts every week. Each of these accounts are structured differently-some using Kubernetes, others using serverless architectures, and yet others still implementing the “simple” VPC-EC2 setup. Regardless of the structure, they all have the same concern:

“Our IAM is complex and probably full of garbage. Could you help us out with it?”

As we’ve helped our customers do exactly that over the past several months, we’ve begun to spot these recurring security issues with AWS IAM setups:

1. It’s easy to bypass

By regularly verifying who has the AdministratorAccess policy attached, you can keep tabs on exactly who has complete access to your AWS account at all times. Even if you run a very tight ship with regards to IAM, attaching a simple policy as seen below to any role/user gives them complete access without the AdministratorPolicy ever knowing about it!

    "Version": "2012-10-17",
    "Statement": [
            "Effect": "Allow"
            "Action": "*"
            "Resource": "*"

2. Its complex relationships make it hard to govern

There are many ways in which a user can attain privileges to an account:

3. It’s hard to enforce access policies over time

Even we’ve been guilty of this. Six months ago, we set a clear rule that all employees must use Multi-Factor Authentication (MFA) with their IAM users. Over time we brought on new engineers, only a portion of whom set up MFA. To identify that gap, I had to go to the AWS console or use the APIs to proactively figure out who the violators were. Even when we migrated to Single Sign-On to avoid using IAM users altogether, we still need to periodically check that no IAM users get created. This is very tedious.

4. There’s no way to know if a privilege is actually being used

Especially in the cloud, things change. What used to run on EC2 moves to ECS, data moved from DynamoDB to another database, maybe even one of your employees changed teams and needs a different set of privileges than the one he had. This fluidity makes it hard to know if a privilege is actually being used and is in stark contrast to the principle of least-privilege.

How can we solve these issues?

At Bridgecrew, we love automating solutions for recurring and tedious issues. We also love open source—we’re the proud creators of Checkov and contributors to many other open source tools. In combining these two passions, we decided to build a new open source tool to help manage AWS IAM by transforming it to Terraform.

In building AirIAM, we set out to provide a simple tool that:

  • Identifies unused users, roles, and groups that have no members or no policies.
  • Identifies policies that are not attached to any user, group, or role.
  • Identifies policy attachments that are not in use by the relevant user, group, or role.
  • Identifies drifts and changes in IAM configurations by using Terraform and leveraging your version control system (VCS).
  • Supports a large scale by using Terraform.
  • Supports stakeholder approval and rollback by leveraging your VCS’s pull/merge request functionality.
  • Reduces the time IAM rightsizing takes by minimizing analysis time to a few minutes and allowing collaboration with the relevant stakeholders in a tool they already know and love.

How does AirIAM work?

AirIAM works by querying your configurations and usage data directly from AWS IAM & Access Advisor APIs. From there, you can either output its findings to the CLI or output Terraform code that, once run by you, will fix your IAM setup.

AirIAM utilizes three commands built one on top of the other:

  • find_unused identifies unused entities in the account.
  • recommend_groups creates groups of access for the existing IAM users, based on the output from find_unused.
  • terraform creates the terraform code and terraform state to allow easier migration. This can take into account the unused entities and/or the groups that are outputted by the previous commands!

Using infrastructure as code to manage AWS IAM can provide many advantages, including least-privilege analysis, identifying bad practices, and fixing misconfigurations at scale. To get started with AirIAM, visit the documentation or check it out on GitHub—contributions are much appreciated!