Introduction to AWS IAM

Understanding IAM - AWS’s Identity and Access Management service - is critical to attacking or defending an AWS account. IAM is a highly complex service with multiple parts. In this module, you’ll learn about:

Why is IAM so important? With traditional network-centric security, you’re dealing with two dimensions. You are either inside the firewall or outside the firewall. With public clouds, like AWS, the network is Software Defined. I issue API calls to AWS to control the network. All of these API calls introduce a third dimension. Suddenly you’re no longer defending castles from opposing armies; you’re defending castles from dragons.

IAM is how AWS manages access to the APIs that control your network - and all the other resources that exist in your account. With the right IAM permissions, I can change your firewalls, update routing tables of your network, and exfiltrate data from your NoSQL databases or object storage. AWS even has several system management tools that efficiently allow you to pop shells on a machine. 

As a defender, you need to understand how to defend your cloud accounts and resources against attacks that leverage IAM. As an attacker, you can leverage AWS IAM in a number of ways to compromise a target, move laterally, and exfiltrate data. 

One of the core principles of identity and access control in AWS is the concept of an AWS Account (opens in new tab).  Amazon treats each account as an independent customer of AWS, and each account is its own independent trust boundary.  Inside an AWS Account, there can be multiple IAM Users, Groups, and Roles.

Terminology can be confusing, and people often refer to granting access as "giving someone an IAM Account".  For clarity, we shall always refer to the AWS Account as an Account and an IAM User inside that account as an IAM User.

Every AWS Account has a root user, and AWS considers that root user the customer.  Major customer-service interactions need to occur from that root user, including billing changes and closing the account.  The root user (opens in new tab) is all-powerful and has complete control over all resources in the account (except for AWS Organizational Service Control Policies which we will discuss in a future room). 

Since the root user is all-powerful, and since there is only one, best-practice is to create individual IAM Users (opens in new tab) for each person who needs access to the account and only grant the level of access required for their job function.  When creating an account for the first time, the common practice is for the root user to create an Admin IAM User and never use root again. 

At this point, day-to-day access should occur via either IAM Users (opens in new tab) or IAM Roles (opens in new tab).  IAM Users combine authentication, identity, and authorization into a single unit.  IAM Roles typically delegate the authentication and identity to another system and primarily manage authorization.  We will discuss Users and Roles in the next Room.

Both IAM Users and IAM Roles require IAM Policies to be able to do anything.  By default, all API requests are implicitly denied.  We will discuss policies and how they work in a future room.  For introductory purposes, the User or Role is the "who" can do something, and the Policy defines the "what" they can do. 

IAM Policies define the actions (opens in new tab) that the user or role can perform on a resource (opens in new tab).  Almost everything you create in AWS is a Resource, and almost all Resources can be identified by their Amazon Resource Name or ARN.  AWS defines an ARN as: 

Amazon Resource Names (ARNs) uniquely identify AWS resources.  We require an ARN when you need to specify a resource unambiguously across all of AWS, such as in IAM policies, Amazon Relational Database Service (Amazon RDS) tags, and API calls (source (opens in new tab))

An ARN consists of the AWS Region, AWS Account ID, Service, and some identifiers for the Resource, commonly the Resource's name.  ARNs are unique across all of AWS.  For example, this is the ARN for an EC2 Instance and an IAM Role:

arn:aws:ec2:us-east-1:123456789012:instance/i-00c07e4f8c9affca3:

arn:aws:iam::123456789012:role/admin-role

Trivia - ARNs almost always begin with "arn:aws:".  The second field is called the partition.  Most AWS customers are in the AWS partition, but there are several other partitions, including GovCloud (aws-us-gov), AWS China Region (aws-cn), and a handful of other Top Secret partitions built for the US Government.  For instance, Chinese Law requires AWS China to operate in partnership with Chinese companies and not solely by Amazon. 

AWS requires the use of an Access Key and Secret Key (and an optional Session Token) to authenticate calls to the AWS APIs.  These keys sign the request and identify which user or role and which AWS account the request comes from.  We will discuss credentials in more detail in a later room.

Multiple AWS Accounts can be members of an AWS Organization.  This is typically done for management and consolidated billing purposes.  Typically there is no implicit trust across accounts in an organization; however, AWS has introduced some new features that blur the boundary and allow the organization management account to modify and manage the member accounts.