RBAC ले ServiceAccount सँग कसरी काम गर्छ, र तपाईं Kubernetes cluster लाई कसरी सुरक्षित बनाउनुहुन्छ?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** ले API मा *कसले के गर्न सक्छ* भन्ने नियन्त्रण गर्छ। अनुमतिहरू **subject** (user, group, **ServiceAccount**) लाई resource मा अनुमति भएका verb सूचीबद्ध गर्ने **Role** सँग **bind** गरेर दिइन्छन्। 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
# 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"]
---
# Bind that Role to a ServiceAccount
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
```

## ServiceAccount: Pod का लागि पहिचान

```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 call नचाहिए opt out गर्नुहोस्
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # यो पहिचानमा Pod चलाउनुहोस्
```

## 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 जिम्मेवारी हो, र ServiceAccount सहितको RBAC यसको जग हो, त्यसैले दुवै बुझ्नु अत्यावश्यक security ज्ञान हो। RBAC मोडेल सुरुचिपूर्ण र आत्मसात् गर्न लायक छ: अनुमतिहरू **पूर्णतया additive, deny बिना** हुन्छन्, **subject** (user, group, र विशेषगरी **ServiceAccount**) लाई resource मा अनुमति भएका **verb** सूचीबद्ध गर्ने **Role** (namespaced) वा **ClusterRole** (cluster-wide) सँग **bind** गरेर दिइन्छन् — जसको अर्थ राम्रो security deny मा भर पर्नुको सट्टा प्रत्येक workload लाई चाहिने कुरा मात्र दिनु (**least privilege**) बाट आउँछ। **ServiceAccount भनेको Pod ले API call गर्न प्रयोग गर्ने पहिचान हो** भन्ने बुझ्नु — प्रत्येक Pod ले token पाउँछ, `default` SA सामान्य over-privilege पासो हो, र तपाईंले प्रत्येक workload लाई आफ्नै least-privilege SA दिनुपर्छ (र API पहुँच नचाहिँदा token automounting बन्द गर्नुपर्छ) — सिधै व्यावहारिक र वास्तविक-संसारको गलत configuration को बारम्बार स्रोत हो। महत्त्वपूर्ण रूपमा, senior इन्जिनियरलाई थाहा हुन्छ RBAC **defense in depth** को एउटा मात्र तह हो: default-deny **NetworkPolicy**, कडा **securityContext** सेटिङ (non-root, read-only root filesystem, हटाइएका capability, seccomp), **Pod Security Admission**, Secret का लागि **encryption at rest** र बाह्य manager, image scanning र signing, admission controller (OPA/Gatekeeper, Kyverno), र बन्द गरिएको etcd/API पहुँच सबै मिलेर cluster जोगाउँछन्। किनभने Kubernetes cluster एउटा उच्च-मूल्यको लक्ष्य हो जहाँ एउटै over-permissioned ServiceAccount वा खुला NetworkPolicy ले पूर्ण सम्झौता निम्त्याउन सक्छ, RBAC र व्यापक hardening toolkit मा दक्षता production मा cluster सुरक्षित रूपमा सञ्चालन गर्ने आधारभूत कुरा हो।

RBAC मोडेल

Role + RoleBinding उदाहरण

ServiceAccount: Pod का लागि पहिचान

Defense in depth — RBAC भन्दा पर

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू