Si funksionon RBAC me ServiceAccount-et, dhe si siguron një cluster Kubernetes?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** qeveris *kush mund të bëjë çfarë* mbi API-në. Lejet u jepen **subjekteve** (përdorues, grupe, **ServiceAccount-e**) duke i **binduar** te **Role** që listojnë verb-e të lejuara mbi resource. RBAC është një shtresë e një strategjie më të gjerë hardening-u cluster-i.

## Modeli RBAC

```text
SUBJECT (user / grup / ServiceAccount)
   │  i binduar nga
   ▼
RoleBinding ───────► Role         (me namespace: leje brenda NJË namespace)
ClusterRoleBinding ► ClusterRole  (në të gjithë cluster-in, ose e ripërdorshme nëpër namespace)

Role/ClusterRole = një bashkësi RULE-sh: "këto VERB mbi këto RESOURCE"
Binding-et janë ADITIVE dhe NUK ka deny — jep vetëm atë që nevojitet.
```

## Shembull Role + RoleBinding

```yaml
# Një Role: akses vetëm-lexim te Pod-et në namespace-in "app"
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 atë Role te një 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-et: identitet për Pod-et

```text
Një ServiceAccount është IDENTITETI që një Pod përdor për të folur me API server-in.
  → Çdo Pod merr një (SA-ja "default" e namespace-it nëse nuk specifikohet).
  → Një token projected mount-ohet në Pod; RBAC vendos çfarë mund të bëjë ai token.
Praktikë e mirë: jepi çdo workload SA-në E VET me RBAC me leje minimale,
dhe vendos automountServiceAccountToken: false kur Pod-i nuk ka nevojë për akses API.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # hiqe nëse nuk nevojiten thirrje API
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # drejto Pod-et nën këtë identitet
```

## Mbrojtje në thellësi — përtej RBAC

```text
AUTH        → RBAC me leje minimale; ServiceAccount për çdo workload; audit të aksesit
NETWORK     → NetworkPolicy default-deny (Pod-et nuk flasin dot pa u lejuar)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, hiq capability
              seccomp profile; Pod Security Admission (restricted) për ta zbatuar
SECRETS     → encryption at rest për etcd; menaxherë të jashtëm secret-esh; RBAC i ngushtë mbi secret
IMAGES      → skano image-t, përdor registry të besuar, zbato me admission (p.sh. policy engine)
API/etcd    → kufizo & enkripto etcd; TLS kudo; kufizo aksesin anonymous & cluster-admin
SUPPLY CHAIN→ image të nënshkruar, 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          # çfarë mund të bëjë përdoruesi aktual?
```

## Pse ka rëndësi

Sigurimi i një cluster-i është një përgjegjësi senior, dhe RBAC me ServiceAccount-e është themeli i tij, kështu që të kuptosh të dyja është njohuri thelbësore sigurie. Modeli RBAC është elegant dhe i vlefshëm për t'u brendësuar: lejet janë **thjesht aditive pa asnjë deny**, të dhëna duke **binduar subjekte** (përdorues, grupe, dhe sidomos **ServiceAccount-e**) te **Role** (me namespace) ose **ClusterRole** (në të gjithë cluster-in) që numërojnë **verb-e të lejuara mbi resource** — që do të thotë se siguria e mirë vjen nga dhënia vetëm e asaj që çdo workload ka nevojë (**leje minimale**) në vend të mbështetjes te deny-t. Të kuptosh që një **ServiceAccount është identiteti që një Pod përdor për të thirrur API-në** — që çdo Pod merr një token, që SA-ja `default` është një kurth i zakonshëm mbi-privilegji, dhe që duhet t'i japësh çdo workload SA-në e vet me leje minimale (dhe të çaktivizosh automount-imin e token-it kur nuk nevojitet akses API) — është drejtpërdrejt praktike dhe një burim i shpeshtë keqkonfigurimi në botën reale. Vendimtare, një inxhinier senior e di që RBAC është vetëm një shtresë e **mbrojtjes në thellësi**: NetworkPolicy default-deny, setting-e **securityContext** të hardened (non-root, root filesystem read-only, capability të hequra, seccomp), **Pod Security Admission**, **encryption at rest** dhe menaxherë të jashtëm për Secret-et, skanim e nënshkrim image-sh, admission controller-a (OPA/Gatekeeper, Kyverno), dhe akses etcd/API i kyçur fort kombinohen të gjitha për të mbrojtur një cluster. Meqë një cluster Kubernetes është një objektiv me vlerë të lartë ku një ServiceAccount i vetëm mbi-privilegjuar ose një NetworkPolicy e hapur mund të çojnë në kompromis të plotë, zotërimi i RBAC dhe i toolkit-it më të gjerë të hardening-ut është themelor për të operuar cluster-a në mënyrë të sigurt në production.

Modeli RBAC

Shembull Role + RoleBinding

ServiceAccount-et: identitet për Pod-et

Mbrojtje në thellësi — përtej RBAC

Pse ka rëndësi

Pyetje të ngjashme