IAM কী এবং AWS-এ এটা কেন সবকিছুর ভিত্তি?

AWS-এ আপনি যা-ই করেন না কেন যেমন একটা EC2 চালু করা, S3 থেকে file পড়া, Lambda function invoke করা – প্রতিটা action-এর পেছনে একটাই প্রশ্ন কাজ করে: “তুমি কে, এবং তোমার permission আছে কি?” এই প্রশ্নের উত্তর দেয় IAM।

IAM মানে Identity and Access Management। এটা AWS-এর authorization এবং authentication layer। কোনো resource access করতে গেলে AWS সবার আগে IAM দিয়ে check করে তারপর বাকি কাজ।

Production-এ IAM misconfiguration মানে হয় data breach, নয়তো কেউ আপনার account-এ ইচ্ছেমতো resource তৈরি করছে। SOA-C03-তে এখান থেকে সবচেয়ে বেশি প্রশ্ন আসে।

Identity, Permission এবং Access

IAM-এর পাঁচটি মূল উপাদান – বিস্তারিত

IAM User একটি নির্দিষ্ট ব্যক্তি বা application-এর জন্য তৈরি identity। এর দুটো credential আছে ১) Console-এর জন্য username/password, ২) programmatic access-এর জন্য Access Key ID + Secret Access Key। এই credentials দীর্ঘমেয়াদী (long-term), তাই এগুলো leak হলে বিপদ।

Production rule: Real human বা service-এর জন্য কখনো IAM User ব্যবহার করবেন না। Human-এর জন্য SSO/Federation, service-এর জন্য IAM Role।

IAM Group Group মানে Users-এর একটা bucket। Group-এ policy attach করলে সেই group-এর সব user সেই permission পায়। Group-এ Group add করা যায় না। Group নিজে কোনো AWS resource access করতে পারে না – শুধু User-দের organize করার জন্য।

IAM Role এটা IAM-এর সবচেয়ে গুরুত্বপূর্ণ concept। Role কোনো permanent identity না এটা assume করতে হয়, এবং assume করলে STS থেকে temporary credentials পাওয়া যায় (default 1 ঘণ্টা, max 12 ঘণ্টা)। EC2 instance, Lambda function, অন্য AWS account, বা federated user সবাই Role assume করতে পারে।

Role-এর দুটো অংশ আছে:

• Trust Policy – কে এই Role assume করতে পারবে (Principal)
• Permission Policy – assume করলে কী করতে পারবে

IAM Policy IAM Policy হলো একটি JSON document, যা define করে – কোন action, কোন resource-এ, কোন condition-এ allow বা deny করা হবে। IAM Policy তিন ধরনের হয়:

Production-এ Inline policy এড়িয়ে চলুন। Delete করতে গেলে identity আগে delete করতে হয়, audit করা কঠিন।

Policy Evaluation Engine – AWS কীভাবে সিদ্ধান্ত নেয়

AWS প্রতিটি API call-এ এই order-এ evaluate করে:

1. Explicit DENY আছে? → সঙ্গে সঙ্গে DENY (কোনো allow এটা override করতে পারবে না)
2. SCP (Organizations) allow করছে?
3. Permission Boundary allow করছে?
4. Identity Policy (User/Role policy) allow করছে?
5. Resource-based Policy allow করছে?
উপরের কোনোটায় explicit Allow না থাকলে → Implicit DENY

মনে রাখুন: AWS-এ সবকিছু default deny। কোনো permission না দিলে কেউ কিছু করতে পারবে না।

STS এবং Credential Chain

STS (Security Token Service) হলো AWS-এর temporary credential issuer। যখন কেউ Role assume করে, STS তিনটা জিনিস দেয়:

• AccessKeyId (temporary)
• SecretAccessKey (temporary)
• SessionToken (expiry সহ)

Credential Chain – AWS CLI/SDK যে order-এ credentials খোঁজে:

1. Code-এ hardcoded (কখনো করবেন না)
2. Environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
3. AWS credentials file (~/.aws/credentials)
4. AWS config file (~/.aws/config)
5. ECS task role / EC2 instance profile (IMDS)
6. SSO / AWS IAM Identity Center

EC2-তে application চালালে instance profile automatically credentials দেয় – কোনো key লাগে না।

AWS Console থেকে IAM Role তৈরি করুন

EC2-এর জন্য S3 Read-only Role তৈরি:

1. AWS Console → IAM → বাম মেনুতে Roles → Create role
2. Trusted entity type: AWS service → Use case: EC2 → Next
3. Permission policies search করুন: AmazonS3ReadOnlyAccess → চেক করুন → Next
4. Role name: ec2-s3-readonly-role
5. Description: দিতে পারেন → Create role

Role তৈরির পর EC2 instance launch করার সময় IAM instance profile-এ এই role select করুন।

CLI দিয়ে IAM Automate করুন

# Create an IAM role with a trust policy for EC2
aws iam create-role \
  --role-name ec2-s3-readonly-role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "ec2.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'

# Attach AWS managed S3 read-only policy to the role
aws iam attach-role-policy \
  --role-name ec2-s3-readonly-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Create an instance profile and add the role to it
aws iam create-instance-profile \
  --instance-profile-name ec2-s3-readonly-profile

aws iam add-role-to-instance-profile \
  --instance-profile-name ec2-s3-readonly-profile \
  --role-name ec2-s3-readonly-role

# Assume a role manually (cross-account or testing)
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/ec2-s3-readonly-role \
  --role-session-name "test-session"

# Verify current caller identity (useful for debugging)
aws sts get-caller-identity

# Enable MFA for a user (virtual MFA device)
aws iam enable-mfa-device \
  --user-name john \
  --serial-number arn:aws:iam::123456789012:mfa/john \
  --authentication-code1 123456 \
  --authentication-code2 789012

# Create an inline policy (avoid in production, shown for reference)
aws iam put-user-policy \
  --user-name john \
  --policy-name emergency-s3-access \
  --policy-document file://policy.json

# policy.json example - deny all except specific S3 bucket
cat > policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::my-specific-bucket",
      "arn:aws:s3:::my-specific-bucket/*"
    ]
  }]
}
EOF

Role ছাড়া কী হত?

ধরুন EC2-তে একটা Python script আছে যেটা S3 থেকে file পড়ে। Role না থাকলে script-টা credentials কোথায় পাবে? আপনাকে হয়:

• Access Key + Secret Key hardcode করতে হত code-এ, অথবা
• .aws/credentials file manually রেখে দিতে হত EC2-তে

দুটোই বিপজ্জনক। কেউ EC2 access পেলে key চুরি হয়ে যাবে।

Role attach করলে কী হয়?

EC2 চালু হওয়ার সাথে সাথে AWS IMDS (Instance Metadata Service) চালু হয়। আপনার EC2-র ভেতর থেকে এই address-এ hit করলে temporary credentials পাওয়া যায়:

# EC2-র ভেতর থেকে run করুন
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-s3-readonly-role

AWS SDK এবং CLI নিজেরাই IMDS থেকে credentials তুলে নেয় আপনাকে কিছু করতে হয় না। আপনার Python script যখন boto3.client('s3') লেখে – boto3 নিজেই IMDS থেকে credentials তুলে নেয়। আপনাকে কোনো key দিতে হয় না।

তাহলে practically কী পার্থক্য?

import boto3

# Role attach থাকলে এটুকুই যথেষ্ট - কোনো key লাগবে না
s3 = boto3.client('s3', region_name='ap-southeast-1')
response = s3.list_buckets()
print(response['Buckets'])

Role না থাকলে এই code চালালে NoCredentialsError আসত।

সংক্ষেপে:

Role attach করা মানে EC2-কে বলা “তুমি আমার হয়ে S3 পড়তে পারবে, কিন্তু কোনো permanent key ছাড়াই।” Credentials automatically rotate হয়, expire হয়, এবং কোথাও store থাকে না। এটাই production-এ করার সঠিক উপায়।

Production-এ যে ভুলগুলো সবাই করে

1. Root account ব্যবহার করা – Root account-এ MFA enable করুন, তারপর ভুলে যান। Day-to-day কাজের জন্য কখনো root use করবেন না।

2. Long-term access key তৈরি করা – EC2, Lambda, ECS – সব জায়গায় Role ব্যবহার করুন। Key rotate করতে ভুলে গেলে বিপদ।

3. * wildcard দিয়ে overly permissive policy – "Action": "*", "Resource": "*" দেখলে production-এ সাথে সাথে flag করুন। Least privilege মানে শুধু যা দরকার ঠিক ততটুকুই।

4. Permission Boundary না বোঝা – Developer নিজেই নিজেকে admin দিতে পারে যদি Permission Boundary না থাকে। Multi-team environment-এ এটা mandatory।

5. Trust Policy ঠিকমতো না লেখা – "Principal": {"AWS": "*"} মানে যে কেউ এই Role assume করতে পারবে। সবসময় specific Principal দিন।

SOA-C03-এ IAM কীভাবে আসে?

IAM থেকে scenario-based প্রশ্ন আসে – সরাসরি definition না।

Sample Question 1: একটি Lambda function S3 থেকে data পড়তে গিয়ে AccessDenied error পাচ্ছে। Lambda function-এ একটি execution role আছে যেখানে AmazonS3ReadOnlyAccess policy attach করা। তবু error আসছে। সবচেয়ে সম্ভাব্য কারণ কোনটি?

A) S3 bucket-এ কোনো bucket policy নেই B) Lambda function-এর memory কম C) S3 bucket-এর bucket policy-তে explicit Deny আছে D) Lambda-কে VPC-তে deploy করা হয়েছে

উত্তর: C – Explicit Deny সবকিছু override করে। Identity policy-তে allow থাকলেও resource-based policy-তে explicit deny থাকলে access হবে না।

Trap: A এবং D দেখতে plausible মনে হয়। A ভুল কারণ bucket policy না থাকলে identity policy-র allow যথেষ্ট। D ভুল কারণ VPC-তে থাকলে VPC endpoint না থাকলেও S3 access কাজ করে (internet দিয়ে)।

Sample Question 2: একটি company-তে নতুন DevOps engineer যোগ দিয়েছে। তাকে EC2 এবং S3 access দিতে হবে, কিন্তু billing information দেখা যাবে না। সবচেয়ে কম operational overhead-এ এটা করার উপায় কোনটি?

A) User-এ inline policy attach করুন

B) একটি Group তৈরি করুন, Group-এ policy attach করুন, User-কে Group-এ add করুন

C) User-এ দুটো আলাদা managed policy attach করুন

D) একটি Role তৈরি করুন এবং User-কে assume করতে বলুন

উত্তর: B – Group-based management কম overhead-এ scalable। নতুন engineer আসলে শুধু Group-এ add করলেই হয়।

আজকের সারাংশ ও আগামীকালের প্রস্তুতি

আজকে আপনি IAM-এর পুরো ছবিটা দেখলেন User, Group, Role, Policy, STS, Credential Chain, এবং Policy Evaluation Engine কীভাবে একসাথে কাজ করে। মূল কথা হলো: Role > User, Managed Policy > Inline, Explicit Deny সর্বোচ্চ অগ্রাধিকার।

আগামীকাল Day 3 – AWS CLI setup – config profiles, named profiles, credential precedence। এটা directly আজকের Credential Chain-এর সাথে connected। CLI দিয়ে multiple AWS account manage করতে গেলে named profile এবং assume-role workflow বুঝতে হবে, যেটা আজকের STS-এর উপর build করে।