ServiceAccountsతో RBAC ఎలా పనిచేస్తుంది, ఒక Kubernetes clusterను మీరు ఎలా secure చేస్తారు?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** APIపై *ఎవరు ఏమి చేయగలరో* నియంత్రిస్తుంది. Permissions **subjects** (users, groups, **ServiceAccounts**)కు, వాటిని resources మీద అనుమతించిన verbs జాబితా చేసే **Roles**కు **bind** చేయడం ద్వారా మంజూరు చేయబడతాయి. RBAC అనేది విస్తృత cluster-hardening వ్యూహంలో ఒక layer.

## 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
# ఒక 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
ServiceAccount అనేది ఒక Pod API serverతో మాట్లాడటానికి వాడే IDENTITY.
  → ప్రతి Pod ఒకటి పొందుతుంది (చెప్పకపోతే namespace "default" SA).
  → ఒక projected token Podలోకి mount అవుతుంది; ఆ token ఏమి చేయగలదో RBAC నిర్ణయిస్తుంది.
ఉత్తమ పద్ధతి: ప్రతి workloadకు least-privilege RBACతో దాని సొంత SA ఇవ్వు,
మరియు Podకు API access అవసరం లేనప్పుడు automountServiceAccountToken: false పెట్టు.
```

```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; access audit
NETWORK     → default-deny NetworkPolicies (అనుమతించనంత వరకు Pods మాట్లాడలేవు)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, capabilities drop
              seccomp profiles; అమలు చేయడానికి Pod Security Admission (restricted)
SECRETS     → etcdకు encryption at rest; external secret managers; secrets మీద గట్టి RBAC
IMAGES      → images scan, trusted registries వాడు, admissionతో అమలు (ఉదా. policy engines)
API/etcd    → etcd పరిమితం & encrypt; TLS ప్రతిచోటా; 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ను secure చేయడం ఒక senior బాధ్యత, మరియు ServiceAccountsతో RBAC దాని పునాది, కాబట్టి రెండింటినీ అర్థం చేసుకోవడం అత్యవసరమైన security జ్ఞానం. RBAC model సొగసైనది మరియు అంతర్గతంగా గ్రహించదగినది: permissions **పూర్తిగా additive, deny లేకుండా**, **subjects** (users, groups, మరియు ముఖ్యంగా **ServiceAccounts**)ను resources మీద అనుమతించిన **verbs** జాబితా చేసే **Roles** (namespaced) లేదా **ClusterRoles** (cluster-wide)కు **bind** చేయడం ద్వారా మంజూరు చేయబడతాయి — అంటే మంచి security denials మీద ఆధారపడటం కాకుండా ప్రతి workloadకు అవసరమైనది మాత్రమే మంజూరు చేయడం నుండి వస్తుంది (**least privilege**). ఒక **ServiceAccount అనేది ఒక Pod APIని call చేయడానికి వాడే identity** అని అర్థం చేసుకోవడం — ప్రతి Pod ఒక token పొందుతుందని, `default` SA ఒక సాధారణ over-privilege trap అని, మరియు మీరు ప్రతి workloadకు దాని సొంత least-privilege SA ఇవ్వాలని (API access అవసరం లేనప్పుడు token automounting disable చేయాలని) — నేరుగా ఆచరణాత్మకం మరియు వాస్తవ misconfigurationకు తరచుగా మూలం. కీలకంగా, ఒక senior engineer RBAC అనేది **defense in depth** యొక్క ఒక layer మాత్రమే అని తెలుసుకుంటారు: default-deny **NetworkPolicies**, గట్టిచేసిన **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), మరియు lock-down చేసిన etcd/API access అన్నీ కలిసి ఒక clusterను రక్షిస్తాయి. ఒక Kubernetes cluster ఒక high-value target కావడంతో ఒక్క over-permissioned ServiceAccount లేదా open NetworkPolicy పూర్తి compromiseకు దారితీయగలదు కాబట్టి, RBAC మరియు విస్తృత hardening toolkit ప్రావీణ్యం productionలో clusters సురక్షితంగా operate చేయడానికి పునాది.

RBAC model

Role + RoleBinding ఉదాహరణ

ServiceAccounts: Podsకు identity

Defense in depth — RBAC దాటి

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు