RBAC، ServiceAccounts کے ساتھ کیسے کام کرتا ہے، اور آپ ایک Kubernetes cluster کو کیسے محفوظ بناتے ہیں؟

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** یہ طے کرتا ہے کہ API پر *کون کیا کر سکتا ہے*۔ اجازتیں **subjects** (users، groups، **ServiceAccounts**) کو **Roles** سے **binding** کر کے دی جاتی ہیں جو resources پر مجاز verbs کی فہرست دیتے ہیں۔ RBAC ایک وسیع تر cluster-hardening حکمتِ عملی کی ایک layer ہے۔

## RBAC ماڈل

```text
SUBJECT (user / group / ServiceAccount)
   │  bound by
   ▼
RoleBinding ───────► Role         (namespaced: permissions within ONE namespace)
ClusterRoleBinding ► ClusterRole  (cluster-wide, or reusable across namespaces)

Role/ClusterRole = a set of RULES: "these VERBS on these RESOURCES"
Bindings are ADDITIVE and there is NO deny — you grant only what's needed.
```

## Role + RoleBinding کی مثال

```yaml
# ایک Role: "app" namespace میں Pods تک صرف پڑھنے کی رسائی
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# اس Role کو ایک ServiceAccount سے bind کریں
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

## ServiceAccounts: Pods کے لیے شناخت

```text
A ServiceAccount is the IDENTITY a Pod uses to talk to the API server.
  → Every Pod gets one (the namespace "default" SA if unspecified).
  → A projected token is mounted into the Pod; RBAC decides what that token can do.
Best practice: give each workload its OWN SA with least-privilege RBAC,
and set automountServiceAccountToken: false when the Pod doesn't need API access.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # اگر API کالز کی ضرورت نہ ہو تو opt out کریں
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # Pods کو اس شناخت کے تحت چلائیں
```

## گہرائی میں دفاع (defense in depth) — RBAC سے آگے

```text
AUTH        → least-privilege RBAC; per-workload ServiceAccounts; audit access
NETWORK     → default-deny NetworkPolicies (Pods can't talk unless allowed)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              seccomp profiles; Pod Security Admission (restricted) to enforce
SECRETS     → encryption at rest for etcd; external secret managers; tight RBAC on secrets
IMAGES      → scan images, use trusted registries, enforce with admission (e.g. policy engines)
API/etcd    → restrict & encrypt etcd; TLS everywhere; limit anonymous & cluster-admin access
SUPPLY CHAIN→ signed images, admission control (OPA/Gatekeeper, Kyverno)
```

```bash
kubectl auth can-i list pods --as=system:serviceaccount:app:my-app -n app
kubectl auth can-i --list -n app          # موجودہ صارف کیا کر سکتا ہے؟
```

## یہ کیوں اہم ہے

ایک cluster کو محفوظ بنانا ایک سینئر ذمہ داری ہے، اور ServiceAccounts کے ساتھ RBAC اس کی بنیاد ہے، اس لیے دونوں کو سمجھنا ایک ضروری security علم ہے۔ RBAC ماڈل خوبصورت اور اندرونی طور پر جذب کرنے کے قابل ہے: اجازتیں **خالصتاً اضافی ہیں، کوئی deny نہیں**، جو **subjects** (users، groups، اور خاص طور پر **ServiceAccounts**) کو **Roles** (namespaced) یا **ClusterRoles** (cluster-wide) سے **bind** کر کے دی جاتی ہیں جو resources پر مجاز **verbs** کو شمار کرتے ہیں — جس کا مطلب ہے کہ اچھی security انکار پر انحصار کرنے کے بجائے صرف وہی دینے سے آتی ہے جو ہر workload کو چاہیے (**کم سے کم اختیار**)۔ یہ سمجھنا کہ ایک **ServiceAccount وہ شناخت ہے جسے ایک Pod API کو کال کرنے کے لیے استعمال کرتا ہے** — کہ ہر Pod کو ایک token ملتا ہے، کہ `default` SA ایک عام حد سے زیادہ اختیار کا جال ہے، اور کہ آپ کو ہر workload کو اپنا کم سے کم اختیار والا SA دینا چاہیے (اور جب API رسائی کی ضرورت نہ ہو تو token automounting بند کر دینا چاہیے) — براہِ راست عملی ہے اور حقیقی دنیا کی غلط کنفیگریشن کا ایک عام سبب ہے۔ نہایت اہم بات، ایک سینئر انجینئر جانتا ہے کہ RBAC **گہرائی میں دفاع** کی صرف ایک layer ہے: default-deny **NetworkPolicies**، سخت کیے گئے **securityContext** settings (non-root، صرف پڑھنے کے قابل root filesystem، ہٹائی گئی capabilities، seccomp)، **Pod Security Admission**، Secrets کے لیے **encryption at rest** اور بیرونی managers، image scanning اور signing، admission controllers (OPA/Gatekeeper، Kyverno)، اور مقفل کیا گیا etcd/API رسائی سب مل کر ایک cluster کی حفاظت کرتے ہیں۔ چونکہ ایک Kubernetes cluster ایک اعلیٰ قدر کا ہدف ہے جہاں ایک اکیلا حد سے زیادہ اختیار والا ServiceAccount یا کھلا NetworkPolicy مکمل تباہی کا سبب بن سکتا ہے، RBAC اور وسیع تر hardening ٹول کٹ پر عبور clusters کو production میں محفوظ طریقے سے چلانے کے لیے بنیادی ہے۔

RBAC ماڈل

Role + RoleBinding کی مثال

ServiceAccounts: Pods کے لیے شناخت

گہرائی میں دفاع (defense in depth) — RBAC سے آگے

یہ کیوں اہم ہے

متعلقہ سوالات