RBAC ServiceAccounts સાથે કેવી રીતે કામ કરે છે, અને તમે Kubernetes cluster ને કેવી રીતે સુરક્ષિત કરો છો?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** API પર *કોણ શું કરી શકે* તેને નિયંત્રિત કરે છે. Permissions **subjects** (users, groups, **ServiceAccounts**) ને એવા **Roles** સાથે **binding** કરીને અપાય છે જે 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 પર read-only access
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 માટે identity

```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       # આ identity હેઠળ 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          # current user શું કરી શકે?
```

## આ શા માટે મહત્વનું છે

cluster ને સુરક્ષિત કરવું એ senior જવાબદારી છે, અને ServiceAccounts સાથે RBAC તેનો પાયો છે, તેથી બંનેને સમજવું આવશ્યક security જ્ઞાન છે. RBAC મોડલ સુઘડ છે અને આત્મસાત કરવા યોગ્ય છે: permissions **સંપૂર્ણપણે additive છે, deny નથી**, જે **subjects** (users, groups, અને ખાસ કરીને **ServiceAccounts**) ને **Roles** (namespaced) કે **ClusterRoles** (cluster-wide) સાથે **binding** કરીને અપાય છે જે **resources પર માન્ય verbs** ગણાવે છે — જેનો અર્થ છે કે સારી security denials પર આધાર રાખવાને બદલે દરેક workload ને જે જોઈએ તે જ આપવાથી (**least privilege**) આવે છે. એ સમજવું કે **ServiceAccount એ identity છે જે Pod API ને call કરવા વાપરે છે** — કે દરેક Pod ને token મળે છે, કે `default` SA એ સામાન્ય over-privilege ફાંદો છે, અને કે તમારે દરેક workload ને પોતાનું least-privilege SA આપવું જોઈએ (અને API access જરૂરી ન હોય ત્યારે token automounting disable કરવું) — એ સીધું વ્યાવહારિક છે અને વાસ્તવિક દુનિયાની misconfiguration નું વારંવારનું કારણ છે. નિર્ણાયક રીતે, એક 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 access — બધું મળીને cluster ને સુરક્ષિત કરે છે. કારણ કે Kubernetes cluster એ ઊંચી-કિંમતનું લક્ષ્ય છે જ્યાં એક જ over-permissioned ServiceAccount કે ખુલ્લી NetworkPolicy સંપૂર્ણ compromise તરફ દોરી શકે, RBAC અને વ્યાપક hardening toolkit પર પ્રભુત્વ મેળવવું એ production માં clusters ને સલામત રીતે operate કરવા માટે પાયાનું છે.

RBAC મોડલ

Role + RoleBinding ઉદાહરણ

ServiceAccounts: Pods માટે identity

Defense in depth — RBAC થી આગળ

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો