🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🪪 धडा 17 — RBAC आणि ServiceAccounts: hall passes

📍 तुम्ही इथे आहात: धडा 17 / 26 · मागील: lesson-16-debugging · पुढील: lesson-18-jobs-cronjobs

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

आधीचे सगळे, आणि: cluster च्या आत कोण काय करू शकते — RBAC — आणि pods साठी ओळखपत्रे: ServiceAccounts.

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

AWS कोर्सने लोकांना cloud साठी ओळखपत्रे दिली (IAM). पण शाळेच्या इमारतीच्या आत दुसरी व्यवस्था आहे: hall passes 🪪.

Role म्हणजे एकाच खोलीचा पास: "school मधले pods पाहू शकतो".
ClusterRole म्हणजे संपूर्ण इमारतीचा पास: "सगळीकडचे pods पाहू शकतो" (काही दरवाजे, जसे nodes, फक्त इमारतीच्या पातळीवरच असतात).
RoleBinding पास कोणाला तरी देते: एखादी व्यक्ती, गट — किंवा ServiceAccount: pod घालतो ते ओळखपत्र. प्रत्येक pod एक घालतो (वेगळे सांगितले नाही तर default), आणि ArgoCD सारखे robots सगळे काही आपल्या ओळखपत्रानेच करतात.

IAM सारखेच कडक नियम: पास परवानगी देत नाही तोपर्यंत काहीच allowed नाही, आणि पासने कामाला लागतील तेवढेच दरवाजे उघडले पाहिजेत. तुमच्या CI robot ला "school मध्ये manifests apply करणे" लागते — cluster-admin नाही. Cluster-admin असलेला CI म्हणजे पुन्हा तीच photocopy केलेली master key. 🗝️😱

(आणि दोन्ही जगांमधला पूल: EKS वर, ServiceAccount ला IAM role शी जोडता येते — IRSA — म्हणजे pod ला AWS टोपी घालता येते. आत hall pass, बाहेर bank badge, कुठेच keys नाहीत.)

🗺️ आकृती

flowchart LR
    who["👥 who<br/>person · group ·<br/>🤖 ServiceAccount (pod's card)"]
    rb["🔗 RoleBinding<br/>hands the pass over"]
    role["🪪 Role<br/>verbs on resources in ONE room:<br/>get/list pods, create deployments"]
    cr["🏫 ClusterRole<br/>same, building-wide"]
    api["🧑‍💼 API server checks the pass<br/>on EVERY request"]
    who --> rb --> role --> api
    rb -.-> cr

❓ काय

नियम = resources (pods, deployments, secrets…) वरचे verbs (get list watch create update delete), हवे तर विशिष्ट नावांसह. Deny rules नाहीत — RBAC फक्त allow करते (IAM च्या उलट).
तयार ClusterRoles: view (वाचणे, secrets नाहीत), edit (बहुतेक writes), admin (खोलीचा मालक), cluster-admin (master key). स्वतःचे लिहिण्याआधी हेच bind करा.
API शी बोलणाऱ्या प्रत्येक workload साठी एक ServiceAccount — बहुतेक app pods (आपल्यासारखे) कधीच बोलत नाहीत, आणि त्यांनी शक्तिहीन default च ठेवावा. वापर नसेल तेव्हा automountServiceAccountToken: false ठेवा (स्वच्छता!).
जादूचा प्रश्न: kubectl auth can-i create deployments -n school — आणि दुसऱ्याचा पास उसना न घेता तपासायला --as=system:serviceaccount:school:ci-bot.

🤔 का

Cluster चा API त्यावर चालणाऱ्या सगळ्यावर root आहे. RBAC म्हणजे "intern ची leak झालेली kubeconfig एक namespace वाचू शकते" आणि "intern ची leak झालेली kubeconfig म्हणजेच cluster" यांतला फरक. Teams न घाबरता एक cluster वाटून घेतात ते यामुळेच (L05 चे namespaces + RBAC = खरी multi-tenancy).

🧪 करून पाहा

# what can YOU do? (local clusters: everything — you're cluster-admin)
kubectl auth can-i delete namespaces && kubectl auth can-i list pods -n school

# make a robot card + a one-room pass + hand it over:
kubectl -n school create serviceaccount report-bot
kubectl -n school create role pod-reader --verb=get,list --resource=pods
kubectl -n school create rolebinding report-bot-reads \
  --role=pod-reader --serviceaccount=school:report-bot

# test the pass WITHOUT wearing it:
kubectl auth can-i list pods -n school --as=system:serviceaccount:school:report-bot   # yes
kubectl auth can-i delete pods -n school --as=system:serviceaccount:school:report-bot # no 🎉
kubectl auth can-i list secrets -n school --as=system:serviceaccount:school:report-bot # no!

# cleanup:
kubectl -n school delete rolebinding report-bot-reads
kubectl -n school delete role pod-reader && kubectl -n school delete sa report-bot

🔧 या धड्यासाठी kubectl

kubectl auth can-i · kubectl get role,rolebinding,sa

🔗 यावर आधारित: 🪪 AWS L03–L04 (policies आणि roles — तीच कल्पना)

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

kubectl auth can-i get pods --as=system:serviceaccount:school:reader हो म्हणते; --as=… delete नाही म्हणते.

🧹 साफसफाई

तुम्ही बनवलेले kubectl delete rolebinding,role …

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

robot ला 'तात्पुरते' cluster-admin bind करणे
चुकीच्या namespace मधला Role — पास प्रत्येक खोलीसाठी वेगळा असतो

⏭️ पुढे

एकदाच चालणारे काम आणि वेळापत्रकानुसार चालणारे काम — यात हा repo त्याच्या README पासून वचन देत आलेला backup CronJob सुद्धा: Jobs आणि CronJobs.

git checkout lesson-18-jobs-cronjobs

🪪 Lesson 17 — RBAC & ServiceAccounts: hall passes

📍 You are here: Lesson 17 of 26 · Previous: lesson-16-debugging · Next: lesson-18-jobs-cronjobs

📦 What's in this branch

Everything before, plus: who may do what inside the cluster — RBAC — and identity cards for pods: ServiceAccounts.

🧒 Explain like I'm 5

The AWS course gave people ID cards for the cloud (IAM). But inside the school building there's a second system: hall passes 🪪.

A Role is a pass for ONE room: "may look at pods in school".
A ClusterRole is a pass for the whole building: "may look at pods everywhere" (some doors, like nodes, only exist building-wide).
A RoleBinding hands the pass to someone: a person, a group — or a ServiceAccount: the ID card a pod wears. Every pod wears one (default unless told otherwise), and robots like ArgoCD do everything with theirs.

Same iron rules as IAM: nothing is allowed until a pass says so, and the pass should open exactly the doors the job needs. Your CI robot needs "apply manifests in school" — not cluster-admin. Cluster-admin CI is the photocopied master key all over again. 🗝️😱

(And the bridge between worlds: on EKS, a ServiceAccount can be linked to an IAM role — IRSA — so a pod can wear an AWS hat. Hall pass inside, bank badge outside, zero keys anywhere.)

🗺️ Diagram

flowchart LR
    who["👥 who<br/>person · group ·<br/>🤖 ServiceAccount (pod's card)"]
    rb["🔗 RoleBinding<br/>hands the pass over"]
    role["🪪 Role<br/>verbs on resources in ONE room:<br/>get/list pods, create deployments"]
    cr["🏫 ClusterRole<br/>same, building-wide"]
    api["🧑‍💼 API server checks the pass<br/>on EVERY request"]
    who --> rb --> role --> api
    rb -.-> cr

❓ What

Rules = verbs (get list watch create update delete) on resources (pods, deployments, secrets…), optionally specific names. No deny rules — RBAC is allow-only (unlike IAM).
Ready-made ClusterRoles: view (read, no secrets), edit (most writes), admin (room master), cluster-admin (the master key). Bind these before writing custom ones.
ServiceAccount per workload that talks to the API — most app pods (like ours) never do, and should keep the powerless default. Set automountServiceAccountToken: false when unused (hygiene!).
The magic question: kubectl auth can-i create deployments -n school — and --as=system:serviceaccount:school:ci-bot to test someone else's pass without borrowing it.

🤔 Why

The cluster's API is root over everything it runs. RBAC is the difference between "the intern's leaked kubeconfig can read one namespace" and "the intern's leaked kubeconfig IS the cluster". It's also how teams share a cluster without fear (namespaces from L05 + RBAC = real multi-tenancy).

🧪 Try it

# what can YOU do? (local clusters: everything — you're cluster-admin)
kubectl auth can-i delete namespaces && kubectl auth can-i list pods -n school

# make a robot card + a one-room pass + hand it over:
kubectl -n school create serviceaccount report-bot
kubectl -n school create role pod-reader --verb=get,list --resource=pods
kubectl -n school create rolebinding report-bot-reads \
  --role=pod-reader --serviceaccount=school:report-bot

# test the pass WITHOUT wearing it:
kubectl auth can-i list pods -n school --as=system:serviceaccount:school:report-bot   # yes
kubectl auth can-i delete pods -n school --as=system:serviceaccount:school:report-bot # no 🎉
kubectl auth can-i list secrets -n school --as=system:serviceaccount:school:report-bot # no!

# cleanup:
kubectl -n school delete rolebinding report-bot-reads
kubectl -n school delete role pod-reader && kubectl -n school delete sa report-bot

🔧 kubectl for this lesson

kubectl auth can-i · kubectl get role,rolebinding,sa

🔗 Builds on: 🪪 AWS L03–L04 (policies & roles — the same idea)

✅ Verify — what you should see

kubectl auth can-i get pods --as=system:serviceaccount:school:reader says yes; --as=… delete says no.

🧹 Clean up

kubectl delete rolebinding,role … you created

⚠️ Common mistakes

binding cluster-admin to a robot 'temporarily'
a Role in the wrong namespace — passes are per room

⏭️ Next

Work that runs once and work that runs on a schedule — including the backup CronJob this repo has been promising since its README: Jobs & CronJobs.

git checkout lesson-18-jobs-cronjobs

← Previousdebugging Next →jobs cronjobs

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