AWS Zero to Hero | Day 2: Deep Dive into AWS IAM (Identity & Access Management)

This chapter provides a comprehensive, practical guide to AWS Identity and Access Management (IAM). We will explore the fundamental concepts of authentication and authorization, examine the core components of IAM (Users, Groups, Policies, and Roles), and walk through a step-by-step practical implementation to secure an AWS environment.

1. Why Do We Need IAM? (The Problem Statement)

When an organization first adopts AWS, a cloud administrator or DevOps engineer creates an AWS account. By default, this account is accessed using the email address and password used during registration. This identity is known as the Root User.

The Danger of Root Access

The Root User has absolute, unrestricted access to every resource, billing detail, and service within the AWS account.

If a DevOps engineer shares these root credentials with everyone in the company (e.g., developers, QA engineers, database administrators):

• Accidental Deletion: An inexperienced user could accidentally delete a production database (DB) or terminate a critical compute instance (EC2).
• Security Compromise: If one person's credentials are leaked, the entire AWS infrastructure is compromised.
• Lack of Auditability: If a critical resource is deleted or modified, it is impossible to trace who performed the action because everyone logged in using the same root identity.

To prevent these catastrophic scenarios, AWS provides Identity and Access Management (IAM). IAM allows you to securely control access to AWS services and resources for your users.

2. The Core Mental Model: The Bank Analogy

To understand how IAM secures an AWS account, consider the real-world analogy of a physical bank.

1. Entering the Bank (Authentication)

To enter the bank, you must first prove who you are. You might need to show an ID card or prove you are an account holder. This process of verifying your identity is Authentication.

2. Accessing Specific Areas (Authorization)

Once inside the bank, your identity determines where you are allowed to go and what you are allowed to do:

• Customers can walk to the service desk to ask queries, but they cannot go behind the counter.
• Bank Employees can sit at the employee desks and access staff laptops.
• The Bank Manager has the keys to the highly sensitive vault containing cash, checks, and user documents.

Verifying what actions an authenticated person is allowed to perform is Authorization.

Without these controls, anyone could walk straight into the vault, take the money, and walk out. IAM acts as the security guard, receptionist, and keycard system for your AWS resources.

3. Authentication vs. Authorization in AWS

In AWS, IAM implements these two distinct security phases:

4. The Four Core Components of IAM

AWS IAM is built upon four foundational pillars:

1. Users

An IAM User represents a specific person or application that interacts with AWS. Each user has their own unique credentials (username/password for the console, or access keys for the CLI).

2. Groups

An IAM Group is a collection of IAM users. Groups allow you to specify permissions for multiple users at once, making permissions management highly scalable.

3. Policies

An IAM Policy is a document (written in JSON) that defines permissions. Policies state precisely what actions are allowed or denied on which AWS resources. Policies can be attached directly to Users, Groups, or Roles.

4. Roles

An IAM Role is an identity with permission policies that determine what the identity can and cannot do in AWS. Unlike a user, a role does not have permanent credentials (like a password or access keys). Instead, it provides temporary security credentials. Roles are typically used by applications running on AWS, services, or users from external accounts.

5. Deep Dive into IAM Policies (The JSON Structure)

IAM Policies are written in JSON (JavaScript Object Notation). They consist of statements that define permissions.

Structure of an IAM Policy Statement

A standard policy statement contains the following key elements:

• Effect: Specifies whether the policy Allows or Denys the access.
• Action: Specifies the specific API calls/operations that are allowed or denied (e.g., s3:ListBucket, ec2:RunInstances).
• Resource: Specifies the AWS resources to which the actions apply (using Amazon Resource Names, or ARNs). Use * to represent all resources.

Example: S3 Full Access Policy

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

Note: AWS provides thousands of pre-configured policies called AWS Managed Policies (e.g., AmazonS3FullAccess, AmazonEC2ReadOnlyAccess). For advanced use cases, you can write your own Customer Managed Policies to enforce fine-grained access control.

6. Step-by-Step Practical Walkthrough

This hands-on exercise demonstrates the difference between authentication and authorization by creating a user, testing their access in a restricted state, and then granting them permissions.

Step 6.1: Creating an IAM User (Authentication Only)

1. Log into your AWS account as the Root User.
2. In the top search bar, search for IAM and select the IAM service.
3. In the left navigation pane, click on Users, then click Create user.

4. Configure the user details:
   • User name: test-user-501
   • Check the box: Provide user access to the AWS Management Console - optional.
   • Select: I want to create an IAM user (instead of Identity Center).
   • Console password: Select Auto-generated password.
   • Check the box: Users must create a new password at next sign-in (recommended).

5. Click Next.
6. On the Set permissions page, select Attach policies directly but do not select any policies. This ensures we are testing a pure "authenticated but unauthorized" state.
7. Click Next, review the configuration, and click Create user.
8. Crucial Step: Copy the Console sign-in URL, User name, and the Password (click Show to view it), or click Download .csv file to save these credentials.

Step 6.2: Testing Authentication (The "Access Denied" State)

1. Open a new Incognito/Private browser window.
2. Paste the Console sign-in URL you copied in the previous step.
3. Enter the Account ID (pre-filled if using the custom URL), the username test-user-501, and the auto-generated password.
4. Upon clicking sign-in, AWS will prompt you to change your password. Enter the old password and set a secure new password.
5. You are now logged in as test-user-501. You have successfully authenticated.
6. Now, test your authorization:
   • Search for S3 in the search bar.
   • Navigate to the S3 dashboard. You will see error messages stating you do not have permission to list buckets.
   • Search for EC2 and navigate to the EC2 dashboard. You will see API errors indicating you are unauthorized to view instances, security groups, or volumes.

Step 6.3: Authorizing the User (Attaching S3 Full Access)

To grant test-user-501 permission to manage S3 storage, we must attach an authorization policy.

1. Switch back to your browser window where you are logged in as the Root User.
2. Navigate back to the IAM Console -> Users -> Click on test-user-501.
3. Under the Permissions tab, click Add permissions -> Add permissions.
4. Select Attach policies directly.
5. In the search box, type S3.
6. Check the box next to AmazonS3FullAccess.

7. Click Next, then click Add permissions.

Step 6.4: Testing Authorization (Successful Bucket Creation)

1. Switch back to the browser window where you are logged in as test-user-501.
2. Refresh the S3 Console page.
3. The "Access Denied" errors will disappear, and you will be able to see the list of existing S3 buckets.
4. Click Create bucket.
5. Enter a globally unique bucket name (e.g., my-aws-demo-test-bucket-1).
6. Scroll to the bottom and click Create bucket. The bucket will be successfully created.

7. Scaling Permissions with IAM Groups

The Problem: Manual Overhead

Imagine your organization grows, and you now have 50 developers joining the team. If you do not use groups, you must:

1. Create 50 individual users.
2. Manually attach the AmazonS3FullAccess policy to each of the 50 users.

If the development team later requests access to EC2, you would have to manually edit all 50 users to attach the AmazonEC2FullAccess policy. This is highly inefficient and prone to human error.

The Solution: IAM Groups

Instead of managing permissions at the individual user level, you manage them at the group level.

Step-by-Step Group Implementation

1. Logged in as the Root User, navigate to IAM Console -> User groups -> Create group.
2. Configure the group:
   • User group name: DevelopmentGroup
   • Add users to the group: Check the box next to test-user-501.
   • Attach permissions policies: Search for and select AmazonS3FullAccess.
3. Click Create group.

Testing Group Inheritance & Updates:

If the development team later needs EC2 access:

1. Go to User groups -> Click on DevelopmentGroup.
2. Go to the Permissions tab -> Click Add permissions -> Attach policies.
3. Search for and attach AmazonEC2FullAccess.
4. Both test-user-501 and any other user added to DevelopmentGroup will instantly inherit EC2 permissions without modifying their individual user accounts.

8. Understanding IAM Roles (Introduction)

While IAM Users are designed for humans who need permanent credentials, IAM Roles are designed for scenarios where resources need temporary access.

Common Use Cases for IAM Roles

• AWS Services accessing other AWS Services: An application running on an EC2 instance needs to read files from an S3 bucket. Instead of hardcoding AWS access keys inside the application code (a massive security risk), you assign an IAM Role to the EC2 instance.
• Applications running outside AWS: A CI/CD tool (like Jenkins) running on-premises needs to deploy resources to AWS.
• Cross-Account Access: Allowing users from AWS Account A to access resources in AWS Account B without creating duplicate users.

Note: We will deep dive into IAM Roles in future chapters when we configure CI/CD pipelines and infrastructure deployments.

9. Production Best Practices & Security Standards

To maintain a secure AWS environment, always adhere to the following industry-standard IAM practices:

• Never Use the Root User for Daily Tasks: Lock away the root credentials and use MFA. Create dedicated IAM users or roles for administrative tasks.
• Apply the Principle of Least Privilege (PoLP): Only grant the minimum permissions necessary for a user or service to perform its job. Never grant wildcard (*) admin access by default.
• Enable Multi-Factor Authentication (MFA): Enforce MFA for all users, especially those with administrative privileges.
• Use Groups to Assign Permissions: Never attach policies directly to individual users. Always assign policies to groups and place users inside those groups.
• Rotate Credentials Regularly: Set up policies to rotate passwords and access keys periodically to minimize the impact of leaked credentials.

10. Hands-On Assignment

To reinforce your learning from Day 2, complete the following assignment in your AWS sandbox environment:

1. Create an IAM User: Create a user named dev-user-test with console access and an auto-generated password.
2. Verify Restricted Access: Log in as dev-user-test and verify that you cannot access S3, EC2, or IAM.
3. Create a User Group: Create a group named S3-Admins and attach the AmazonS3FullAccess policy to it.
4. Add User to Group: Add dev-user-test to the S3-Admins group.
5. Verify Access: Log back in as dev-user-test and verify that you can now list, create, and delete S3 buckets, but still cannot access EC2.
6. Clean Up: Delete the S3 bucket you created, remove the user from the group, and delete both the user and the group to keep your account clean.

11. Summary and Key Takeaways

• IAM (Identity and Access Management) is the core security service in AWS that handles both Authentication (who you are) and Authorization (what you can do).
• The Root User has absolute power and should never be used for daily administrative or development tasks.
• IAM Users are persistent identities created for individuals or applications requiring long-term credentials.
• IAM Policies are JSON documents that explicitly define permissions using Effect, Action, and Resource elements.
• IAM Groups simplify access management by allowing you to apply permission policies to collections of users simultaneously.
• IAM Roles provide temporary security credentials and are ideal for machine-to-machine communication, AWS services, and cross-account access.
• The Principle of Least Privilege is the golden rule of cloud security: grant only the access required to complete the task, and nothing more.