🤖 धडा 05 — Machine identities: robots साठी badges, keys कोणासाठीच नाहीत

📍 तुम्ही इथे आहात: 12 पैकी धडा 05 · मागे: lesson-04-roles · पुढे: lesson-06-iam-hygiene

📦 या ब्रँचमध्ये काय आहे

धडे 01–04, आणि त्यासोबत: machines स्वतःची ओळख कशी पटवतात — तुमच्या infrastructure मधून दीर्घकाळ टिकणारी गुपिते काढून टाकणारी पद्धत. खऱ्या files:

iam/ec2-role-trust-policy.json — EC2 टोपीचा trust दस्तऐवज
iam/ecr-push-policy.json — CI robot ला लागणाऱ्या नेमक्या चिठ्ठ्या

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

शाळेत robots सुद्धा काम करतात: बाक-computers (EC2) आणि courier (CI). त्यांनी passwords बाळगावेत का? 😬 Robots गोष्टी हरवतात, त्यांच्या खिशांचे फोटो निघतात (logs! repos!), आणि robot चा password कोणीच rotate करत नाही. म्हणून शाळा जास्त हुशारीचे काहीतरी करते — badges, दर तासाला ताजे दिलेले 🪪🤖:

बाक-computer चा badge: बाक तयार होताना कार्यालय त्याला एक टोपी अडकवते (एक instance profile — धडा 04 ची टोपी, hardware वर बसवलेली). बाकाच्या आत एक छोटी खाच असते (metadata service) जिथे machine ला नेहमी आजचा ताजा badge मिळतो — तात्पुरती credentials, आपोआप नूतनीकरण होणारी. k8s course चे EKS nodes ECR मधून नेमके याच पद्धतीने pull करतात. Keys नाहीत. कधीच नाहीत.
Courier चा badge (OIDC): courier येतो आणि सांगतो "मी BaluRaut/learn-docker-school चा, main branch वरचा CI run आहे". AWS courier कंपनीला (GitHub/CircleCI चा OIDC issuer) फोन करतो — "हा robot खरोखर तुमचा आहे का, त्याच branch वरचा?" — आणि तेव्हाच एका ठराविक टोपीसाठी 15 मिनिटांचा badge देतो. CI settings मध्ये काहीच साठवलेले नसते.
चुकीची पद्धत (anti-pattern) ❌: कायमच्या AKIA… keys असलेला IAM user बनवून त्या CI मध्ये paste करणे. हे चालते — आणि AWS accounts compromise होण्याचा हा #1 मार्ग आहे. एकदा फुटली (एखादा log, fork, screenshot), की कायमची वैध.

🗺️ आकृती

flowchart LR
    ec2["🖥️ EC2 instance<br/>hat clipped on via<br/>instance profile"]
    meta["🪪 metadata service<br/>hands fresh temp creds<br/>auto-renewed"]
    ci["📮 CI run<br/>proves itself via OIDC:<br/>'repo X, branch main'"]
    role["🎩 a role<br/>least-privilege slips only"]
    aws["☁️ AWS APIs<br/>push to ECR, read S3…"]
    bad["❌ AKIA keys in CI settings<br/>permanent, leakable, unrotated"]
    ec2 -->|"1"| meta --> role
    ci -->|"2 15-min badge"| role
    role -->|"3"| aws
    bad -.->|"the way NOT to"| aws

❓ काय

Instance profile = IAM role ला EC2 instance वर बसवणारी यांत्रिक क्लिप (ec2/ec2.tf आपली जोडणी करते). Instance मधील SDK/CLI credentials आपोआप शोधतात — code ला शून्य config लागतो.
OIDC federation = AWS बाहेरच्या identity provider च्या सही केलेल्या tokens वर विश्वास ठेवतो. GitHub Actions चे role-to-assume (Docker course, धडा 12) हेच आहे. CircleCI सुद्धा याला support करते.
Least privilege ची साखळी: trust policy कोण (हा repo, ही branch!) हे मर्यादित करते + permission policy काय हे मर्यादित करते (ecr-push-policy.json: एक repo, फक्त push ची क्रियापदे).

🤔 का

चांगल्या बांधलेल्या AWS setup मधले passwords मोजा: root (बंद करून ठेवलेला), तुमचा SSO login… आणि बस. Server credentials नाहीत, CI secrets नाहीत, config-file मधल्या keys नाहीत. प्रत्येक machine identity म्हणजे एक टोपी + एक ताजा badge. ही एकच पद्धत cloud च्या इतिहासातील सर्वात सामान्य प्रकारचा breach निवृत्त करते.

🧪 करून पाहा (मोफत — कागदावरचा lab + एक खरी तपासणी)

# see whether any permanent keys exist in your account (goal: none/minimal):
aws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | while read u; do
  aws iam list-access-keys --user-name "$u" \
    --query "AccessKeyMetadata[].[UserName,AccessKeyId,Status,CreateDate]" --output text
done
# every AKIA line: ask "could this be a role instead?" (usually: yes)

# read the two real documents in this repo and say aloud what each allows:
cat iam/ec2-role-trust-policy.json     # WHO may wear the hat
cat iam/ecr-push-policy.json           # WHAT the wearer may do
# (lesson 12 of Part 2 mounts this hat on a real instance — and you'll
#  curl the metadata service from inside it!)

✅ तपासा — तुम्हाला काय दिसायला हवे

instance मधून metadata endpoint वर curl (आधी IMDSv2 token) मुदत असलेली तात्पुरती credentials परत देतो; aws sts get-caller-identity instance role दाखवतो.

🧹 साफसफाई — काहीही चालू ठेवू नका

lab instance चे terraform destroy करा; 'तुलना करण्यासाठी' बनवलेल्या कोणत्याही access keys delete करा

⚠️ नेहमीच्या चुका

CI settings मध्ये AKIA… access keys — OIDC → role वापरा
फक्त pull करणाऱ्या instance role ला ecr:* — least privilege robots ना सुद्धा लागू होते
IMDSv1 चालू ठेवणे — token अनिवार्य करा (http_tokens = "required")

⏭️ पुढे

भाग 1 ओळखपत्र कार्यालयाच्या भिंतीवरच्या पोस्टरने संपतो: सर्वात सामान्य AWS सुरक्षा चुका टाळणारी स्वच्छतेची checklist.

git checkout lesson-06-iam-hygiene

🤖 Lesson 05 — Machine identities: badges for robots, keys for nobody

📍 You are here: Lesson 05 of 12 · Previous: lesson-04-roles · Next: lesson-06-iam-hygiene

📦 What's in this branch

Lessons 01–04, plus: how machines authenticate — the pattern that removes long-lived secrets from your infrastructure. Real files:

iam/ec2-role-trust-policy.json — the EC2 hat's trust document
iam/ecr-push-policy.json — the exact slips a CI robot needs

🧒 Explain like I'm 5

Robots work at the school too: the desk-computers (EC2) and the courier (CI). Should they carry passwords? 😬 Robots lose things, their pockets get photographed (logs! repos!), and nobody rotates a robot's password. So the school does something smarter — badges, issued fresh every hour 🪪🤖:

A desk-computer's badge: when a desk is set up, the office clips a hat to it (an instance profile — lesson 04's hat, mounted on hardware). Inside the desk there's a little slot (the metadata service) where the machine can always find today's fresh badge — temporary credentials, auto-renewed. The k8s course's EKS nodes pull from ECR exactly this way. No keys. Ever.
The courier's badge (OIDC): the courier arrives claiming "I'm the CI run for BaluRaut/learn-docker-school, main branch". AWS phones the courier company (GitHub/CircleCI's OIDC issuer) — "is this robot really yours, on that branch?" — and only then hands over a 15-minute badge for ONE specific hat. Nothing stored in CI settings at all.
The anti-pattern ❌: minting an IAM user with permanent AKIA… keys and pasting them into CI. It works — and it's the #1 way AWS accounts get compromised. Leaked once (a log, a fork, a screenshot), valid forever.

🗺️ Diagram

flowchart LR
    ec2["🖥️ EC2 instance<br/>hat clipped on via<br/>instance profile"]
    meta["🪪 metadata service<br/>hands fresh temp creds<br/>auto-renewed"]
    ci["📮 CI run<br/>proves itself via OIDC:<br/>'repo X, branch main'"]
    role["🎩 a role<br/>least-privilege slips only"]
    aws["☁️ AWS APIs<br/>push to ECR, read S3…"]
    bad["❌ AKIA keys in CI settings<br/>permanent, leakable, unrotated"]
    ec2 -->|"1"| meta --> role
    ci -->|"2 15-min badge"| role
    role -->|"3"| aws
    bad -.->|"the way NOT to"| aws

❓ What

Instance profile = the mechanical clip that mounts an IAM role onto an EC2 instance (ec2/ec2.tf wires ours). The SDK/CLI inside the instance finds credentials automatically — code needs zero config.
OIDC federation = AWS trusts an external identity provider's signed tokens. GitHub Actions' role-to-assume (Docker course, lesson 12) is this. CircleCI supports it too.
The chain of least privilege: trust policy narrows WHO (this repo, this branch!) + permission policy narrows WHAT (ecr-push-policy.json: one repo, push verbs only).

🤔 Why

Count the passwords in a well-built AWS setup: root (locked away), your SSO login… and that's it. No server credentials, no CI secrets, no config-file keys. Every machine identity is a hat + a fresh badge. This single pattern retires the most common breach class in cloud history.

🧪 Try it (free — paper lab + one real check)

# see whether any permanent keys exist in your account (goal: none/minimal):
aws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | while read u; do
  aws iam list-access-keys --user-name "$u" \
    --query "AccessKeyMetadata[].[UserName,AccessKeyId,Status,CreateDate]" --output text
done
# every AKIA line: ask "could this be a role instead?" (usually: yes)

# read the two real documents in this repo and say aloud what each allows:
cat iam/ec2-role-trust-policy.json     # WHO may wear the hat
cat iam/ecr-push-policy.json           # WHAT the wearer may do
# (lesson 12 of Part 2 mounts this hat on a real instance — and you'll
#  curl the metadata service from inside it!)

✅ Verify — what you should see

from the instance, curl on the metadata endpoint (IMDSv2 token first) returns temporary credentials with an expiry; aws sts get-caller-identity shows the instance role.

🧹 Clean up — do not leave running

terraform destroy the lab instance; delete any access keys you created 'to compare'

⚠️ Common mistakes

AKIA… access keys in CI settings — use OIDC → role
an instance role with ecr:* when it only pulls — least privilege applies to robots too
IMDSv1 left enabled — require the token (http_tokens = "required")

⏭️ Next

Part 1 closes with the poster on the ID-office wall: the hygiene checklist that prevents the most common AWS security mistakes.

git checkout lesson-06-iam-hygiene

← Previousroles Next →iam hygiene

This page is the lesson's README from the lesson-05-machine-identities branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.