AWS IAM: From Basics to Advanced

by Sophnel Merzier 6 months ago 9 min read

IAM is a crucial part of managing security in Amazon Web Services (AWS).

But what is it?

At its core, IAM is all about who can do what in your AWS account. Think of it as the gatekeeper. It lets you decide who is allowed to enter your AWS cloud space and what they can do once they're in. In AWS, “who” could be a person, a service, or even an application, and “what they can do” ranges from reading data from a database to launching a new virtual server.

In this guide, we'll explore the key aspects of IAM, from the basic concepts like users and permissions to more advanced features like role boundaries and trust policies. So, let's get started on this journey to master AWS IAM.

I — How IAM Works

Let's break down some key IAM terms and concept:

Principal : A principal is like a person or thing that can make a request in AWS. It can be a user (like an employee), a service (like Amazon S3), or even an application. The principal is essentially who is asking for access.
Request: When a principal wants to do something in AWS, they make a request. For example, a user might request to open a file stored in AWS, or a service might request to launch a new virtual server, it is evaluated against IAM policies to determine if it should be allowed or denied.
Authentication : This is the process of proving who the principal is. Think of it like showing your ID card before entering a secure building. In AWS, this often means providing a username and password, an access key, or some other form of identity verification.
Authorization: Authorization is about deciding if a principal can do what they're asking to do. After the principal is authenticated, AWS checks if they have the right permissions.
Actions: Actions are the specific tasks that a principal can perform . These can be simple things like reading a file or more complex actions like creating a new database.
Resources: Resources are the actual items in AWS that the principals interact with. These could be anything like an Amazon S3 bucket where data is stored, an EC2 instance (virtual server), or a database in RDS.

Let's use an example.

Note that in a standard IAM policy, “Authentication” is not a field since it's a process rather than a policy attribute.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/Sophnel"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::example-bucket/*"
        }
    ]
}

IAM Policy

In this policy:

Principal: "AWS": "arn:aws:iam::123456789012:user/Sophnel"

The principal is the entity (user, role, service, etc.) that is allowed or denied access. In IAM policies attached to users or roles, this field is usually implicit and not included. It's more commonly used in resource-based policies, like those in S3 or SNS.

Action: "s3:GetObject"

This specifies what actions the principal can perform.
In this example, the action is s3:GetObject, which allows the principal to read objects from the specified S3 bucket.

Resource: "arn:aws:s3:::example-bucket/*"

This defines on which resources the actions can be performed.
Here, it's all objects (/*) in the example-bucket S3 bucket.

Effect: "Allow"

This indicates whether the actions are allowed or denied. Possible values are “Allow” or “Deny”.
In this case, it's allowing the specified actions.

Authentication:

Not a field in the policy, but an essential part of the IAM process.
The principal must authenticate (e.g., log in) before AWS evaluates this policy to grant or deny the specified actions.

Optional and Required Fields

Principal: Optional in IAM user/role policies but required in resource-based policies.
Action: Required. You must specify what actions the policy allows or denies.
Resource: Required. Policies must specify which resources the actions apply to.
Effect: Required. Policies need to specify whether they allow or deny the actions.

Remember, the structure and fields of an IAM policy can vary depending on its use (e.g., attached to a user/role or used as a resource-based policy). In user/role policies, the principal is usually the user/role itself and not explicitly stated. In resource-based policies (like those used in S3 buckets), the principal must be specified.

Understanding these terms helps to grasp how IAM works. It's all about managing who (principal) can do what (actions) with which items (resources) securely (authentication and authorization).

In the following sections, we'll learn about each of these aspects and see how they come together to form the backbone of AWS security.

II — IAM Fundamentals

In this section, we will learn more about the core components of IAM.

IAM Users: Think of an IAM User as an individual identity for anyone or anything that needs to access AWS. It's like having a personal profile.
IAM Groups: Groups are like departments in a company. Each group contains multiple users, and you manage permissions for the whole group, not each person individually.
IAM Roles: They are used to granting specific permissions not to users directly, but to entities (like users, applications, or services) for a limited time.
IAM Policies: Policies are documents that clearly outline permissions. They describe what actions are allowed or denied in AWS.

Least Privilege Principle

This principle means giving someone only the permissions they need to do their job – nothing more. It’s like giving a key card that only opens the doors someone needs to access. It reduces the risk of someone accidentally (or intentionally) doing something harmful.

This foundational understanding of IAM will set the stage for exploring more advanced topics.

III — Advanced Concepts in IAM

In this section, we go deeper into some advanced IAM concepts that play a critical role in managing access and security in AWS.

Service Roles

Service Roles are special types of IAM roles designed specifically for AWS services to interact with other services. They are like permissions given to AWS services to perform specific tasks on your behalf.

For example, you might have an AWS Lambda function that needs to access your S3 buckets . You create a service role for Lambda that gives it the necessary permissions to read and write to your S3 buckets.

These roles are crucial for automating tasks within AWS and for enabling different AWS services to work together seamlessly and securely.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::MyExampleBucket/*"
    }
  ]
}

The role this policy is attached to, for example MyLambdaFunctionwill allow it to perform any action on MyExampleBucket.

2. IAM Boundaries

IAM Boundaries is an advanced feature in AWS IAM that helps in further tightening security. These boundaries are essentially guidelines or limits you set to control the maximum permissions that IAM roles and users can have.

Purpose: Boundaries are used to ensure that even administrators or other high-privileged users can't grant more permissions than intended. This is particularly useful in large organizations or environments where strict compliance and security guidelines are necessary.
How They Work: Imagine setting up a fence around what an IAM user or role can do. Even if someone can assign permissions, they can't go beyond what's defined by this fence. It's a safety net to prevent excessive privileges.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::MyExampleBucket/*"
    }
  ]
}

In this case, DevRole can only read from and write to MyExampleBucket, regardless of what other permissions she's given.

3. Trust Policies

In AWS, a trust policy is attached to a role and defines which entities (like an AWS service or another AWS account) are allowed to assume the role. It's like saying, “This ID badge can only be used by these specific people or roles.”

Function: They act as a rule book stating which AWS entities can use a certain set of permissions.
Example: If you have a service role for AWS EC2, the trust policy specifies that only Ec2 can assume this role, ensuring that the permissions are used only by the intended service.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
      "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Here, EC2 instances can assume the MyEC2Function role .

4. IAM Policy with Conditions and Context Keys

IAM policy conditions are additional specifications you can include in a policy to control when it applies. Think of them like extra rules in a game that apply only under certain circumstances.
Context keys are the specific elements within a request that a condition checks against. They are the details that trigger the conditions.

How They Work: These conditions can check many factors, like the time of the request, the requester's IP address, whether they used Multi-Factor Authentication (MFA), and more.
Example: You could create a policy that allows access to a resource only if the request comes during business hours or from a specific office location.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::MyExampleBucket/*",
      "Condition": {
        "IpAddress": {"aws:SourceIp": "192.168.100.0/24"},
        "DateGreaterThan": {"aws:CurrentTime": "2023-01-01T09:00:00Z"},
        "DateLessThan": {"aws:CurrentTime": "2023-01-01T17:00:00Z"}
      }
    }
  ]
}

This policy will authorize the roles, users or groups it attached to access to MyExampleBucket, but only from the specified IP range and during specified hours.

5. Cross-Account Access Management

In larger organizations, you often have multiple AWS accounts. Cross-account access management is about allowing users from one AWS account to access resources in another.

Method: You create a role in one account (the resource account) and grant permissions to a user in another account (the accessing account) to assume this role.
Security: Trust policies play a crucial role here, specifying which accounts can access the role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
      "Action": "sts:AssumeRole"
    }
  ]
}

In this example, users from Account B (ID 123456789012) can assume the CrossAccountRole in Account A.

6. IAM Role Chaining

Role chaining occurs when an IAM role assumes another role. It's like passing a baton in a relay race; one role hands over permissions to another.

Limitations: This process has a one-hour maximum duration and some restrictions, like not being able to access resources for which the original role didn't have permission.
Use Case: It's often used in complex scenarios where multiple levels of access and separation of duties are needed.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/SecondRole"
    }
  ]
}

Here, InitialRole can pass its permissions to SecondRole for further actions.

Let's say you have an IAM user named DevUser who needs to perform actions that require different permissions from time to time, perhaps for deploying a service. Instead of giving DevUser a broad range of permissions, you give them permission to assume SecondRole, which has the necessary permissions for that deployment task.

When DevUser runs a deployment script, they first assume SecondRole using the AssumeRole action. AWS STS then provides DevUser with temporary credentials. With these credentials, DevUser temporarily has the permissions of SecondRole and can carry out the deployment.

This follows the principle of least privilege by only granting permissions as needed for specific tasks, which is a security best practice. It also provides an audit trail because actions taken with the assumed role can be traced back to the original entity that assumed the role, ensuring accountability and easier troubleshooting in complex environments.

By incorporating these advanced IAM concepts into your AWS strategy, you'll be better equipped to handle complex security and access requirements. These features allow for greater flexibility, precision, and control in managing access to your AWS resources, ensuring that your cloud environment remains both robust and secure.

IV - Relationships Between AWS IAM Components

The schema shows the relationships between different IAM components. The goal is to provide an easy way of understanding how they work with each other.

IAM Users:

Direct Permissions: Users can be assigned Identity-Based Policies that grant them direct permissions to perform actions on AWS resources.
Group Membership: Users can be part of Groups, and through this membership, they inherit any Identity-Based Policies attached to those Groups.
Permissions Boundaries: Users can have Permissions Boundaries applied to them, which restrict the maximum permissions they can have, regardless of what is directly assigned to them or inherited from Groups.
Role Assumption: Users can assume Roles if allowed by the Role's Trust Policy, temporarily gaining the permissions associated with those Roles.

IAM Groups:

Shared Permissions: Groups are used to manage permissions for multiple Users. They don't have their own permissions but can have Identity-Based Policies attached. These policies grant permissions to all Users within the Group.
No Direct Boundaries: Groups cannot have Permissions Boundaries applied to them. Boundaries are applied at the User or Role level.

IAM Roles:

Assumable Permissions: Roles are assumable sets of permissions that Users or AWS services can take on temporarily. They allow for more flexible and secure permission delegation.
Identity-Based Policies: Roles can have Identity-Based Policies attached, which specify the permissions that the entity assuming the Role will obtain.
Trust Policies: Roles have Trust Policies, which define which principals (Users or AWS services) are allowed to assume the Role.
Permissions Boundaries: Roles can also have Permissions Boundaries that restrict the maximum permissions that can be granted by the Role.

To conclude, AWS Identity and Access Management (IAM) is an essential component for managing security and access within the AWS ecosystem.

Key takeaways include:

The importance of the principle of least privilege
The role of trust policies in defining who can assume specific roles
The use of permissions boundaries to limit the maximum permissions assignable to users and roles.

Additionally, advanced concepts like service roles, cross-account access management, and role chaining offer sophisticated methods to handle complex access requirements and ensure seamless, secure operations across multiple services and accounts.