Kako RBAC radi sa ServiceAccountima i kako osigurati Kubernetes klaster?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** upravlja *tko što smije* na API-ju. Dozvole se dodjeljuju **subjektima** (korisnici, grupe, **ServiceAccounti**) tako da ih se **poveže (bind)** s **Roleovima** koji navode dopuštene glagole (verbs) na resursima. RBAC je jedan sloj šire strategije ojačavanja klastera.

## 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.
```

## Primjer Role + RoleBinding

```yaml
# Role: read-only pristup Podovima u namespaceu "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"]
---
# Poveži taj Role sa ServiceAccountom
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
```

## ServiceAccounti: identitet za Podove

```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   # isključi ako API pozivi nisu potrebni
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # pokreni Podove pod ovim identitetom
```

## Obrana u dubinu — iznad RBAC-a

```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          # što trenutni korisnik smije?
```

## Zašto je to važno

Osiguravanje klastera senior je odgovornost, a RBAC sa ServiceAccountima njegov je temelj, pa je razumijevanje oboje bitno sigurnosno znanje. RBAC model je elegantan i vrijedan usvajanja: dozvole su **isključivo aditivne bez zabrana (deny)**, dodijeljene **povezivanjem subjekata** (korisnici, grupe i posebno **ServiceAccounti**) s **Roleovima** (namespaced) ili **ClusterRoleovima** (cijeli klaster) koji nabrajaju dopuštene **glagole na resursima** — što znači da dobra sigurnost dolazi iz dodjeljivanja samo onoga što svaki workload treba (**najmanja privilegija**) umjesto oslanjanja na zabrane. Razumijevanje da je **ServiceAccount identitet koji Pod koristi za poziv API-ja** — da svaki Pod dobiva token, da je `default` SA česta zamka pretjeranih privilegija te da biste svakom workloadu trebali dati vlastiti SA s najmanjom privilegijom (i onemogućiti automatsko montiranje tokena kad API pristup nije potreban) — izravno je praktično i čest izvor stvarne pogrešne konfiguracije. Presudno, senior inženjer zna da je RBAC samo jedan sloj **obrane u dubinu**: default-deny **NetworkPolicyji**, ojačane postavke **securityContexta** (non-root, read-only root datotečni sustav, uklonjene capabilitiesi, seccomp), **Pod Security Admission**, **enkripcija u mirovanju** i vanjski upravitelji za Secrete, skeniranje i potpisivanje imagea, admission controlleri (OPA/Gatekeeper, Kyverno) te zaključan pristup etcd-u/API-ju — sve se to kombinira za zaštitu klastera. Budući da je Kubernetes klaster meta visoke vrijednosti gdje jedan preprivilegirani ServiceAccount ili otvoren NetworkPolicy može dovesti do potpune kompromitacije, ovladavanje RBAC-om i širim priborom za ojačavanje temeljno je za siguran pogon klastera u produkciji.

RBAC model

Primjer Role + RoleBinding

ServiceAccounti: identitet za Podove

Obrana u dubinu — iznad RBAC-a

Zašto je to važno

Povezana pitanja