RBAC কীভাবে ServiceAccount-এর সাথে কাজ করে, এবং আপনি কীভাবে একটি Kubernetes cluster সুরক্ষিত করেন?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** নিয়ন্ত্রণ করে API-তে *কে কী করতে পারে*। অনুমতি **subject**-কে (user, group, **ServiceAccount**) দেওয়া হয় তাদের **Role**-এর সাথে **bind** করে যা resource-এর উপর অনুমোদিত verb তালিকাভুক্ত করে। 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 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
```

## ServiceAccount: Pod-এর জন্য 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 call দরকার না হলে বাদ দিন
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # এই identity-তে 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 এর ভিত্তি, তাই দুটোই বোঝা অপরিহার্য নিরাপত্তা জ্ঞান। RBAC মডেল মার্জিত ও আত্মস্থ করার যোগ্য: অনুমতি **সম্পূর্ণ additive, কোনো deny নেই**, **subject** (user, group, এবং বিশেষত **ServiceAccount**)-কে **Role** (namespaced) বা **ClusterRole** (cluster-wide)-এ **bind** করে দেওয়া হয় যা resource-এর উপর অনুমোদিত **verb** গণনা করে — যার মানে ভালো নিরাপত্তা আসে অস্বীকৃতির উপর নির্ভর না করে প্রতিটি workload-এর যা দরকার কেবল তা মঞ্জুর করা থেকে (**least privilege**)। বোঝা যে একটি **ServiceAccount হলো সেই identity যা একটি Pod API কল করতে ব্যবহার করে** — যে প্রতিটি Pod একটি token পায়, যে `default` SA একটি সাধারণ অতি-অনুমতির ফাঁদ, এবং যে আপনার প্রতিটি workload-কে তার নিজের least-privilege SA দেওয়া উচিত (এবং API access দরকার না হলে token automounting নিষ্ক্রিয় করা) — সরাসরি ব্যবহারিক এবং বাস্তব-জগতের ভুল-কনফিগারেশনের একটি ঘন ঘন উৎস। গুরুত্বপূর্ণভাবে, একজন senior ইঞ্জিনিয়ার জানেন RBAC হলো **defense in depth**-এর কেবল একটি স্তর: default-deny **NetworkPolicy**, দৃঢ় **securityContext** সেটিং (non-root, read-only root filesystem, dropped capability, seccomp), **Pod Security Admission**, **encryption at rest** ও Secret-এর জন্য external manager, image scanning ও signing, admission controller (OPA/Gatekeeper, Kyverno), এবং locked-down etcd/API access সবই মিলে একটি cluster রক্ষা করে। যেহেতু একটি Kubernetes cluster একটি উচ্চ-মূল্যের লক্ষ্য যেখানে একটি একক অতি-অনুমোদিত ServiceAccount বা খোলা NetworkPolicy পূর্ণ compromise-এ নিয়ে যেতে পারে, RBAC ও বৃহত্তর hardening টুলকিট আয়ত্ত করা production-এ cluster নিরাপদে চালানোর জন্য ভিত্তিমূলক।

RBAC মডেল

Role + RoleBinding উদাহরণ

ServiceAccount: Pod-এর জন্য identity

Defense in depth — RBAC-এর বাইরে

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন