RBAC ServiceAccounts के साथ कैसे काम करता है, और आप एक Kubernetes cluster को कैसे सुरक्षित करते हैं?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** यह नियंत्रित करता है कि *कौन API पर क्या कर सकता है*। अनुमतियाँ **subjects** (users, groups, **ServiceAccounts**) को उन्हें **Roles** से **bind** करके दी जाती हैं जो resources पर अनुमत verbs सूचीबद्ध करते हैं। RBAC एक व्यापक cluster-hardening रणनीति की एक परत है।

## 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
एक ServiceAccount वह पहचान है जिसका उपयोग एक Pod API server से बात करने को करता है।
  → हर Pod को एक मिलता है (अनिर्दिष्ट होने पर namespace की "default" SA)।
  → एक projected token Pod में mount होता है; RBAC तय करता है वह token क्या कर सकता है।
सर्वोत्तम अभ्यास: हर workload को least-privilege RBAC के साथ अपनी SA दें,
और जब Pod को API पहुँच न चाहिए तो automountServiceAccountToken: false सेट करें।
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # कोई API call न हो तो बाहर निकलें
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # इस पहचान के तहत Pods चलाएँ
```

## Defense in depth — RBAC से परे

```text
AUTH        → least-privilege RBAC; प्रति-workload ServiceAccounts; पहुँच का audit
NETWORK     → default-deny NetworkPolicies (Pods तब तक बात नहीं कर सकते जब तक अनुमति न हो)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, capabilities हटाएँ
              seccomp profiles; लागू करने हेतु Pod Security Admission (restricted)
SECRETS     → etcd के लिए encryption at rest; बाहरी secret managers; secrets पर कसा RBAC
IMAGES      → images scan करें, भरोसेमंद registries उपयोग करें, admission से लागू करें (policy engines)
API/etcd    → etcd सीमित व encrypt करें; हर जगह TLS; anonymous व cluster-admin पहुँच सीमित करें
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          # वर्तमान user क्या कर सकता है?
```

## यह क्यों महत्वपूर्ण है

एक cluster को सुरक्षित करना एक senior ज़िम्मेदारी है, और ServiceAccounts के साथ RBAC इसकी नींव है, इसलिए दोनों को समझना आवश्यक security ज्ञान है। RBAC मॉडल सुरुचिपूर्ण और आत्मसात करने योग्य है: अनुमतियाँ **विशुद्ध रूप से additive हैं, कोई deny नहीं**, जो **subjects** (users, groups, और ख़ासकर **ServiceAccounts**) को उन **Roles** (namespaced) या **ClusterRoles** (cluster-wide) से **bind** करके दी जाती हैं जो resources पर अनुमत **verbs** गिनाते हैं — जिसका अर्थ है कि अच्छी security denials पर निर्भर रहने के बजाय हर workload को केवल जो चाहिए वही देने (**least privilege**) से आती है। यह समझना कि एक **ServiceAccount वह पहचान है जिसका उपयोग एक Pod API को call करने को करता है** — कि हर Pod को एक token मिलता है, कि `default` SA एक आम अति-विशेषाधिकार जाल है, और कि आपको हर workload को उसकी अपनी least-privilege SA देनी चाहिए (और जब API पहुँच न चाहिए तो token automounting अक्षम करनी चाहिए) — सीधे व्यावहारिक और वास्तविक-दुनिया की ग़लत configuration का लगातार स्रोत है। महत्वपूर्ण रूप से, एक senior इंजीनियर जानता है कि RBAC **defense in depth** की केवल एक परत है: default-deny **NetworkPolicies**, कठोर **securityContext** settings (non-root, read-only root filesystem, हटाई गई capabilities, seccomp), **Pod Security Admission**, Secrets के लिए **encryption at rest** और बाहरी managers, image scanning व signing, admission controllers (OPA/Gatekeeper, Kyverno), और locked-down etcd/API पहुँच सब मिलकर एक cluster की रक्षा करते हैं। चूँकि एक Kubernetes cluster एक उच्च-मूल्य लक्ष्य है जहाँ एक अकेली अति-अनुमति वाली ServiceAccount या खुली NetworkPolicy पूर्ण compromise तक ले जा सकती है, RBAC और व्यापक hardening toolkit में महारत production में clusters को सुरक्षित रूप से संचालित करने की नींव है।

RBAC मॉडल

Role + RoleBinding उदाहरण

ServiceAccounts: Pods के लिए पहचान

Defense in depth — RBAC से परे

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न