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 model

```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
# A Role: read-only access to Pods in the "app" namespace
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 calls लागत नसल्यास 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          # सध्याचा user काय करू शकतो?
```

## हे का महत्त्वाचे आहे

cluster सुरक्षित करणे ही एक senior जबाबदारी आहे, आणि ServiceAccounts सोबतचे RBAC हा त्याचा पाया आहे, त्यामुळे दोन्ही समजून घेणे हे अत्यावश्यक security ज्ञान आहे. RBAC model सुरेख आणि आत्मसात करण्याजोगे आहे: परवानग्या **पूर्णपणे 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 हा एक सामान्य over-privilege सापळा आहे, आणि तुम्ही प्रत्येक workload ला स्वतःचा least-privilege SA द्यावा (आणि API प्रवेश लागत नसताना token automounting बंद करावे) — थेट व्यावहारिक आणि वास्तविक जगातील चुकीच्या configuration चे वारंवार कारण आहे. निर्णायकपणे, एका senior engineer ला माहीत असते की RBAC हा **defense in depth** चा फक्त एक स्तर आहे: default-deny **NetworkPolicies**, hardened **securityContext** settings (non-root, read-only root filesystem, dropped capabilities, seccomp), **Pod Security Admission**, Secrets साठी **encryption at rest** व external managers, image scanning व signing, admission controllers (OPA/Gatekeeper, Kyverno), आणि locked-down etcd/API प्रवेश हे सर्व एकत्र येऊन cluster चे संरक्षण करतात. Kubernetes cluster हे एक उच्च-मूल्याचे लक्ष्य आहे जिथे एकच over-permissioned ServiceAccount किंवा खुले NetworkPolicy पूर्ण compromise कडे नेऊ शकते म्हणून, RBAC व व्यापक hardening toolkit वर प्रभुत्व मिळवणे clusters production मध्ये सुरक्षितपणे चालवण्यासाठी मूलभूत आहे.

RBAC model

Role + RoleBinding उदाहरण

ServiceAccounts: Pods साठी ओळख

Defense in depth — RBAC पलीकडे

हे का महत्त्वाचे आहे

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