Kaip RBAC veikia su ServiceAccount'ais ir kaip apsaugoti Kubernetes klasterį?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** valdo, *kas ką gali* daryti su API. Leidimai suteikiami **subjektams** (naudotojams, grupėms, **ServiceAccount'ams**) juos **susiejant (binding)** su **Role'ėmis**, išvardijančiomis leidžiamus veiksmus (verbs) su resursais. RBAC yra vienas platesnės klasterio grūdinimo strategijos sluoksnis.

## RBAC modelis

```text
SUBJEKTAS (naudotojas / grupė / ServiceAccount)
   │  susietas per
   ▼
RoleBinding ───────► Role         (namespaced: leidimai VIENAME namespace)
ClusterRoleBinding ► ClusterRole  (visame klasteryje arba pakartotinai per namespace'us)

Role/ClusterRole = TAISYKLIŲ rinkinys: "šie VEIKSMAI su šiais RESURSAIS"
Susiejimai yra PRIDEDANTYS ir NĖRA deny — suteikiate tik tai, ko reikia.
```

## Role + RoleBinding pavyzdys

```yaml
# Role: tik skaitymo priėjimas prie Pod'ų "app" namespace'e
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# Susieti tą Role su 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'ai: tapatumas Pod'ams

```text
ServiceAccount yra TAPATUMAS, kurį Pod'as naudoja kalbėdamas su API serveriu.
  → Kiekvienas Pod'as gauna vieną (namespace "default" SA, jei nenurodyta).
  → Į Pod'ą prijungiamas projected token'as; RBAC lemia, ką tas token'as gali.
Gera praktika: kiekvienam workload'ui duokite SAVO SA su least-privilege RBAC
ir nustatykite automountServiceAccountToken: false, kai Pod'ui API priėjimo nereikia.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # atsisakyti, jei API kvietimų nereikia
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # paleisti Pod'us su šiuo tapatumu
```

## Gynyba per gylį — daugiau nei RBAC

```text
AUTH        → least-privilege RBAC; SA kiekvienam workload'ui; priėjimo auditas
NETWORK     → default-deny NetworkPolicies (Pod'ai negali kalbėtis, jei neleista)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              seccomp profiliai; Pod Security Admission (restricted) įtvirtinimui
SECRETS     → encryption at rest etcd'ui; išoriniai secret valdikliai; griežtas RBAC secret'ams
IMAGES      → skenuoti image'us, naudoti patikimus registry, įtvirtinti su admission (pvz., policy engines)
API/etcd    → riboti ir šifruoti etcd; TLS visur; riboti anonyminį ir cluster-admin priėjimą
SUPPLY CHAIN→ pasirašyti image'ai, 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          # ką dabartinis naudotojas gali daryti?
```

## Kodėl tai svarbu

Klasterio apsauga yra senior atsakomybė, o RBAC su ServiceAccount'ais yra jos pamatas, tad suprasti abu yra esminė saugumo žinia. RBAC modelis yra elegantiškas ir vertas įsisavinti: leidimai yra **grynai pridedantys, be deny**, suteikiami **susiejant subjektus** (naudotojus, grupes ir ypač **ServiceAccount'us**) su **Role'ėmis** (namespaced) ar **ClusterRole'ėmis** (visame klasteryje), išvardijančiomis leidžiamus **veiksmus su resursais** — o tai reiškia, kad geras saugumas kyla iš to, kad suteikiate tik tai, ko kiekvienam workload'ui reikia (**least privilege**), o ne remiatės draudimais. Supratimas, kad **ServiceAccount yra tapatumas, kurį Pod'as naudoja kviesdamas API** — kad kiekvienas Pod'as gauna token'ą, kad `default` SA yra dažnas per didelių leidimų spąstas ir kad kiekvienam workload'ui reikia duoti savo least-privilege SA (bei išjungti token'o automontavimą, kai API priėjimo nereikia) — yra tiesiogiai praktiškas ir dažnas realaus pasaulio klaidingos konfigūracijos šaltinis. Kritiškai, senior inžinierius žino, kad RBAC yra tik vienas **gynybos per gylį** sluoksnis: default-deny **NetworkPolicies**, sugrūdinti **securityContext** nustatymai (non-root, tik skaitymui root failų sistema, atmesti capabilities, seccomp), **Pod Security Admission**, **encryption at rest** ir išoriniai valdikliai Secret'ams, image skenavimas ir pasirašymas, admission controller'iai (OPA/Gatekeeper, Kyverno) bei užrakintas etcd/API priėjimas — visa tai kartu saugo klasterį. Kadangi Kubernetes klasteris yra didelės vertės taikinys, kur vienas per daug leidimų turintis ServiceAccount ar atviras NetworkPolicy gali privesti prie visiško kompromitavimo, RBAC ir platesnio grūdinimo įrankių įvaldymas yra pamatinis saugiai eksploatuoti klasterius production aplinkoje.

RBAC modelis

Role + RoleBinding pavyzdys

ServiceAccount'ai: tapatumas Pod'ams

Gynyba per gylį — daugiau nei RBAC

Kodėl tai svarbu

Susiję klausimai