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 ਰਣਨੀਤੀ ਦੀ ਇੱਕ ਪਰਤ ਹੈ।

## 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 ਵਿੱਚ Pod ਲਈ read-only ਪਹੁੰਚ
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: Pod ਲਈ ਪਛਾਣ

```text
ਇੱਕ ServiceAccount ਉਹ IDENTITY ਹੈ ਜੋ ਇੱਕ 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 ਨਾ ਚਾਹੀਦੀ ਹੋਵੇ ਤਾਂ opt out ਕਰੋ
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # ਇਸ ਪਛਾਣ ਹੇਠ Pod ਚਲਾਓ
```

## Defense in depth — RBAC ਤੋਂ ਪਰੇ

```text
AUTH        → least-privilege RBAC; ਹਰ-workload ServiceAccounts; ਪਹੁੰਚ audit ਕਰੋ
NETWORK     → default-deny NetworkPolicies (Pod ਗੱਲ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜਦੋਂ ਤੱਕ ਇਜਾਜ਼ਤ ਨਾ ਹੋਵੇ)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, capabilities drop ਕਰੋ
              seccomp profiles; ਲਾਗੂ ਕਰਨ ਲਈ Pod Security Admission (restricted)
SECRETS     → etcd ਲਈ encryption at rest; ਬਾਹਰੀ secret managers; secrets 'ਤੇ ਤੰਗ RBAC
IMAGES      → image 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 deny 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਦੀ ਬਜਾਏ ਸਿਰਫ਼ ਉਹੀ ਦੇਣ ਤੋਂ ਆਉਂਦੀ ਹੈ ਜੋ ਹਰ workload ਨੂੰ ਚਾਹੀਦਾ ਹੈ (**least privilege**)। ਇਹ ਸਮਝਣਾ ਕਿ **ਇੱਕ ServiceAccount ਉਹ ਪਛਾਣ ਹੈ ਜੋ ਇੱਕ Pod API ਨੂੰ call ਕਰਨ ਲਈ ਵਰਤਦਾ ਹੈ** — ਕਿ ਹਰ Pod ਨੂੰ ਇੱਕ token ਮਿਲਦਾ ਹੈ, ਕਿ `default` SA ਇੱਕ ਆਮ over-privilege ਜਾਲ ਹੈ, ਅਤੇ ਕਿ ਤੁਹਾਨੂੰ ਹਰ workload ਨੂੰ ਆਪਣਾ least-privilege SA ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ (ਅਤੇ ਜਦੋਂ ਕੋਈ API ਪਹੁੰਚ ਨਾ ਚਾਹੀਦੀ ਹੋਵੇ ਤਾਂ token automounting ਬੰਦ ਕਰੋ) — ਸਿੱਧਾ ਵਿਹਾਰਕ ਹੈ ਅਤੇ ਅਸਲ-ਦੁਨੀਆ ਦੀ ਗ਼ਲਤ-ਸੰਰਚਨਾ ਦਾ ਇੱਕ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲਾ ਸਰੋਤ ਹੈ। ਅਹਿਮ ਤੌਰ 'ਤੇ, ਇੱਕ senior engineer ਜਾਣਦਾ ਹੈ ਕਿ RBAC **defense in depth** ਦੀ ਸਿਰਫ਼ ਇੱਕ ਪਰਤ ਹੈ: default-deny **NetworkPolicies**, ਸਖ਼ਤ ਕੀਤੀਆਂ **securityContext** settings (non-root, read-only root filesystem, dropped 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 ਇੱਕ ਉੱਚ-ਮੁੱਲ ਵਾਲਾ ਨਿਸ਼ਾਨਾ ਹੈ ਜਿੱਥੇ ਇੱਕ ਇਕੱਲਾ over-permissioned ServiceAccount ਜਾਂ ਖੁੱਲ੍ਹੀ NetworkPolicy ਪੂਰੇ ਸਮਝੌਤੇ (compromise) ਵੱਲ ਲੈ ਜਾ ਸਕਦੀ ਹੈ, RBAC ਅਤੇ ਵੱਡੇ hardening toolkit ਵਿੱਚ ਮੁਹਾਰਤ production ਵਿੱਚ cluster ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪਰਿਚਾਲਿਤ ਕਰਨ ਦੀ ਨੀਂਹ ਹੈ।

RBAC ਮਾਡਲ

Role + RoleBinding ਉਦਾਹਰਣ

ServiceAccounts: Pod ਲਈ ਪਛਾਣ

Defense in depth — RBAC ਤੋਂ ਪਰੇ

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ