SRJahirTech

AWS + Linux Combo — Part 7: IAM Roles, Users, and Policies

By Suraj Ahir October 25, 2025 6 min read

IAM stands for Identity and Access Management. It is the AWS service that controls who can do what in your AWS account. Understanding IAM is not optional if you want to use AWS seriously — it is the foundation of AWS security. Every AWS action, whether clicking in the console or running an AWS CLI command, is governed by IAM.

Why IAM Matters

In the previous lesson, we used access keys to configure the AWS CLI. That approach works, but it has a major problem: access keys are long-lived credentials that can be stolen. If someone gets your key ID and secret key, they can do anything in your AWS account that your user has permission to do. This has caused massive security breaches and accidental bills in the thousands of dollars for many developers.

The right approach for EC2 instances is to use IAM Roles — temporary credentials that AWS automatically manages. No keys to store, no keys to leak.

IAM Core Concepts

• Users — Individual people or service accounts with permanent credentials (password or access keys).
• Groups — Collections of users. Assign policies to groups instead of individual users for easier management.
• Roles — Identities that can be assumed by AWS services (like EC2), users, or external accounts. Roles use temporary credentials that auto-rotate.
• Policies — JSON documents that define what actions are allowed or denied on which resources.

Understanding IAM Policies

Policies are the rules. Every permission in AWS is controlled by a policy. Here is what a policy looks like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-srjahir-bucket-2026",
        "arn:aws:s3:::my-srjahir-bucket-2026/*"
      ]
    }
  ]
}

This policy allows reading objects from a specific S3 bucket and listing its contents. It does not allow deleting or uploading. AWS policies follow the principle of least privilege — grant only the permissions actually needed.

Creating an IAM Role for EC2

Go to AWS Console → IAM → Roles → Create role. For the trusted entity type, select "AWS service" and choose EC2. This means EC2 instances can assume this role. Click Next and search for the policy "AmazonS3ReadOnlyAccess". Select it and click Next. Name the role "EC2-S3-Reader" and create it.

Attaching a Role to Your EC2 Instance

Go to EC2 → Instances → select your instance → Actions → Security → Modify IAM role → select "EC2-S3-Reader" → Update IAM role. Now your EC2 instance automatically has permission to read from S3 — no access keys needed.

# SSH into EC2 and try listing S3 (no aws configure needed now)
aws s3 ls

# If you see your buckets, the role is working correctly

# Check what credentials are being used
aws sts get-caller-identity

IAM Best Practices

The root account you used to create AWS should never be used for everyday work. Create an IAM admin user for your daily use. Enable MFA (Multi-Factor Authentication) on the root account and on any IAM users with significant permissions. Use roles instead of access keys wherever possible. Apply the principle of least privilege — give each user, role, or service only the minimum permissions it actually needs. Regularly review and remove permissions that are no longer needed.

# Create a new IAM user
aws iam create-user --user-name devuser

# Attach a policy to the user
aws iam attach-user-policy   --user-name devuser   --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# List user's policies
aws iam list-attached-user-policies --user-name devuser

Common Managed Policies

AWS provides hundreds of pre-built "managed policies" you can attach to users, groups, or roles. Common ones include AdministratorAccess (full admin — use sparingly), AmazonS3FullAccess, AmazonEC2ReadOnlyAccess, AmazonDynamoDBFullAccess, and AWSLambdaBasicExecutionRole. For most EC2 use cases, create custom policies with only the specific permissions needed rather than using broad managed policies.

In Part 8, we will write Bash scripts to automate common AWS and Linux tasks — combining everything we have learned so far into practical automation.

IAM Policy Deep Dive

IAM policies are JSON documents that define permissions. Understanding policy structure allows you to write precise, minimal policies rather than using overly broad managed policies:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ReadSpecificS3Bucket",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::my-app-bucket",
                "arn:aws:s3:::my-app-bucket/*"
            ]
        },
        {
            "Sid": "DenyDeleteOperations",
            "Effect": "Deny",
            "Action": "s3:DeleteObject",
            "Resource": "arn:aws:s3:::my-app-bucket/*"
        }
    ]
}

The policy evaluation logic: explicit Deny always overrides Allow. If there is no explicit Allow, access is implicitly denied. This means you must explicitly Allow every action you want to permit — being specific about resources (using ARNs rather than wildcards where possible) is both more secure and required for passing AWS security reviews.

Service Control Policies for Multi-Account Organizations

In AWS Organizations — the service for managing multiple AWS accounts — Service Control Policies (SCPs) provide guardrails that apply to entire organizational units regardless of what IAM policies within individual accounts permit. SCPs cannot grant permissions but can restrict what is possible. A common SCP prevents disabling of CloudTrail logging across all accounts in an organization — even account administrators cannot disable audit logging. This provides organization-wide security guarantees that cannot be overridden by individual account mistakes.

Practice Exercise

Create an IAM user with no permissions, then create a custom policy that grants read-only access to a specific S3 bucket and attach it to the user. Configure the AWS CLI with the user's access keys and verify you can list the bucket contents but cannot write or delete. Then modify the policy to add write access and verify. Finally, use the IAM Policy Simulator in the AWS console to test what actions are allowed for different policy combinations before applying them to production resources.