🪪 धडा 02 — Users & groups: कार्डे आणि कर्मचारी याद्या

📍 तुम्ही इथे आहात: 12 पैकी धडा 02 · मागे: lesson-01-why-iam · पुढे: lesson-03-policies

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

धडा 01, आणि त्यासोबत: माणसांसाठी ओळखी — users — आणि परवानग्या सांभाळण्याजोग्या ठेवणारी युक्ती — groups.

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

ओळखपत्र कार्यालय उघडते. प्रत्येक व्यक्तीला तिच्या नावाचे स्वतःचे कार्ड 🪪 मिळते: aishwarya, katrina, balasaheb. कोणीही कार्डे वाटून घेत नाही — कार्डे वाटून घेतली की धडा 01 मधला गोंधळ पुन्हा सुरू होतो.

पण कार्ड-दर-कार्ड परवानग्या देणे लवकरच हास्यास्पद होते: 20 शिक्षिका × 10 परवानग्या = सांभाळायच्या 200 गोष्टी, आणि प्रत्येक नवी शिक्षिका आली की हे सगळे पुन्हा करायचे. कार्यालयाची युक्ती: कर्मचारी याद्या 📋 (groups).

"teachers" नावाची यादी बनवा. परवानगी चिठ्ठ्या लोकांना नव्हे, त्या यादीला जोडा.
नवी शिक्षिका आली? तिचे कार्ड यादीत जोडा — सगळे अधिकार लगेच मिळतात. शिक्षिका गेली? यादीतून काढा — सगळे अधिकार गेले.
एक व्यक्ती अनेक याद्यांत असू शकते: katrina "teachers" मध्येही आहे आणि "exam-setters" मध्येही.

कार्यालय हळुवारपणे एक नियम पाळते: कार्डे माणसांसाठी आहेत. Robots (servers, CI) ना धडा 04 मध्ये त्याहून चांगले काहीतरी मिळते — कारण कार्डांसोबत passwords येतात, आणि robots कडे passwords मुळीच नसावेत.

🗺️ आकृती

flowchart LR
    a["🪪 user: aishwarya"]
    s["🪪 user: katrina"]
    n["🆕 user: new-teacher"]
    g["📋 group: teachers<br/>permissions live HERE"]
    p["📝 policies<br/>'may manage EC2'<br/>'may read reports'"]
    a -->|"1 member"| g
    s -->|"1 member"| g
    n -.->|"3 join list → powers instantly"| g
    p -->|"2 attached to the GROUP"| g

❓ काय

User = एकाच माणसाची कायमची ओळख: console password (MFA सह!) आणि/किंवा API access keys (शक्य तिथे टाळा — धडा 05).
Group = users ची पिशवी; policies तिला जोडल्या जातात; सदस्यत्व = परवानगी. Groups एकमेकांच्या आत ठेवता येत नाहीत, आणि "assume" करता येत नाहीत — त्या फक्त पिशव्या आहेत.
आधुनिक टीप: कंपन्यांसाठी IAM Identity Center (SSO) बहुतेक IAM users ची जागा घेते — माणसे short-lived sessions ने login करतात. तेच मानसिक चित्र (लोक → groups → परवानग्या), जास्त चांगली स्वच्छता. आधी users शिका; SSO त्याच संकल्पनेला सुटसुटीत करते.

🤔 का

परवानग्या व्यक्तींना नव्हे तर संस्थेतील भूमिकांना ("teachers") जोडणे हा वाढीमध्ये टिकणारा एकमेव मार्ग आहे: नवे कोणी येणे म्हणजे एक command, कोणी जाणे म्हणजे एक command, आणि audit 200 चिकट चिठ्ठ्यांऐवजी संस्थेच्या तक्त्यासारखे वाचता येते.

🧪 करून पाहा (मोफत)

# make the list, then a card, then connect them:
aws iam create-group --group-name learners
aws iam create-user  --user-name test-student
aws iam add-user-to-group --group-name learners --user-name test-student

# give the LIST a permission (read-only everything, an AWS-managed policy):
aws iam attach-group-policy --group-name learners \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

# what can test-student do, and via what?
aws iam list-groups-for-user --user-name test-student
aws iam list-attached-group-policies --group-name learners

# cleanup (labs leave no trace):
aws iam detach-group-policy --group-name learners --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
aws iam remove-user-from-group --group-name learners --user-name test-student
aws iam delete-user --user-name test-student
aws iam delete-group --group-name learners

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

aws iam list-groups-for-user --user-name aishwarya तो group दाखवतो; aws iam list-attached-group-policies --group-name teachers policy user ला नव्हे, group ला जोडलेली दाखवतो.

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

साफ करण्यासारखे काही नाही — हा धडा मोफत आहे 🎉

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

users ना एकेक करून policies जोडणे — group ला जोडा
AdministratorAccess असलेला developers group (तो group नाही, तो जास्तीच्या पायऱ्या असलेला root आहे)
group आणि policy नसलेला user काहीच करू शकत नाही हे विसरणे — ते बरोबर आहे, बिघाड नाही

⏭️ पुढे

"परवानगी चिठ्ठी" म्हणजे नेमके काय? policy JSON वाचणे आणि लिहिणे — AWS चे प्रत्येक दार बोलते ती भाषा.

git checkout lesson-03-policies

🪪 Lesson 02 — Users & groups: cards and staff lists

📍 You are here: Lesson 02 of 12 · Previous: lesson-01-why-iam · Next: lesson-03-policies

📦 What's in this branch

Lesson 01, plus: identities for humans — users — and the trick that keeps permissions manageable — groups.

🧒 Explain like I'm 5

The ID-card office opens. Every person gets their own card 🪪 with their name on it: aishwarya, katrina, balasaheb. Nobody shares cards — sharing cards is how lesson 01's mess restarts.

But giving permissions card-by-card gets silly fast: 20 teachers × 10 permissions = 200 things to manage, and every new teacher means re-doing all of it. The office's trick: staff lists 📋 (groups).

Make a list called "teachers". Attach the permission slips to the LIST, not to people.
New teacher joins? Add their card to the list — all powers arrive instantly. Teacher leaves? Remove from the list — all powers gone.
People can be on several lists: katrina is on "teachers" AND "exam-setters".

One rule the office enforces gently: cards are for humans. Robots (servers, CI) get something better in lesson 04 — because cards come with passwords, and robots shouldn't have passwords at all.

🗺️ Diagram

flowchart LR
    a["🪪 user: aishwarya"]
    s["🪪 user: katrina"]
    n["🆕 user: new-teacher"]
    g["📋 group: teachers<br/>permissions live HERE"]
    p["📝 policies<br/>'may manage EC2'<br/>'may read reports'"]
    a -->|"1 member"| g
    s -->|"1 member"| g
    n -.->|"3 join list → powers instantly"| g
    p -->|"2 attached to the GROUP"| g

❓ What

User = a permanent identity for ONE human: console password (with MFA!) and/or API access keys (avoid where possible — lesson 05).
Group = a bag of users; policies attach to it; membership = permission. Groups can't be nested, and can't be "assumed" — they're just bags.
Modern note: for companies, IAM Identity Center (SSO) replaces most IAM users — humans log in via short-lived sessions. Same mental model (people → groups → permissions), better hygiene. Learn users first; they're the concept SSO streamlines.

🤔 Why

Attaching permissions to roles-in-the-organization ("teachers") instead of individuals is the only version that survives growth: onboarding is one command, offboarding is one command, and an audit reads like an org chart instead of 200 sticky notes.

🧪 Try it (free)

# make the list, then a card, then connect them:
aws iam create-group --group-name learners
aws iam create-user  --user-name test-student
aws iam add-user-to-group --group-name learners --user-name test-student

# give the LIST a permission (read-only everything, an AWS-managed policy):
aws iam attach-group-policy --group-name learners \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

# what can test-student do, and via what?
aws iam list-groups-for-user --user-name test-student
aws iam list-attached-group-policies --group-name learners

# cleanup (labs leave no trace):
aws iam detach-group-policy --group-name learners --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
aws iam remove-user-from-group --group-name learners --user-name test-student
aws iam delete-user --user-name test-student
aws iam delete-group --group-name learners

✅ Verify — what you should see

aws iam list-groups-for-user --user-name aishwarya lists the group; aws iam list-attached-group-policies --group-name teachers shows the policy attached to the group, not the user.

🧹 Clean up — do not leave running

nothing to clean up — this lesson is free 🎉

⚠️ Common mistakes

attaching policies to users one by one — attach to the group
a developers group with AdministratorAccess (that's not a group, that's root with extra steps)
forgetting that a user with no group and no policy can do nothing — that's correct, not broken

⏭️ Next

What exactly IS a "permission slip"? Reading and writing policy JSON — the language every AWS door speaks.

git checkout lesson-03-policies

← Previouswhy iam Next →policies

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