Kako deluje RBAC skupaj s ServiceAccounti in kako zavarujete gručo Kubernetes?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** ureja *kdo lahko kaj počne* na API. Dovoljenja se podelijo **subjektom** (uporabnikom, skupinam, **ServiceAccountom**) tako, da se jih **poveže (bind)** z **Rolami**, ki naštevajo dovoljene glagole (verbs) na virih. RBAC je ena plast širše strategije utrjevanja (hardening) gruče.

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

## Primer Role + RoleBinding

```yaml
# A Role: read-only access to Pods in the "app" namespace
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 that Role to a 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
```

## ServiceAccounti: identiteta za Pode

```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   # izklopi, če klici API niso potrebni
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # poganjaj Pode pod to identiteto
```

## Obramba v globino — onkraj 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          # kaj lahko počne trenutni uporabnik?
```

## Zakaj je to pomembno

Zavarovanje gruče je odgovornost senior inženirja, RBAC skupaj s ServiceAccounti pa je njena osnova, zato je razumevanje obojega bistveno varnostno znanje. Model RBAC je eleganten in vreden ponotranjenja: dovoljenja so **čisto seštevalna, brez zavrnitev (deny)**, podeljena tako, da se **subjekti povežejo (bind)** (uporabniki, skupine in še posebej **ServiceAccounti**) z **Rolami** (namespaced) ali **ClusterRolami** (na ravni celotne gruče), ki naštevajo dovoljene **glagole (verbs) na virih** — kar pomeni, da dobra varnost izhaja iz podeljevanja samo tistega, kar vsaka delovna obremenitev potrebuje (**najmanjše privilegije**), ne pa iz zanašanja na zavrnitve. Razumevanje, da je **ServiceAccount identiteta, ki jo Pod uporablja za klicanje API-ja** — da vsak Pod dobi žeton, da je SA `default` pogosta past prekomernega privilegija in da bi moral vsak workload dobiti svoj SA z najmanjšimi privilegiji (in izklop samodejnega priklopa žetona, kadar dostop do API ni potreben) — je neposredno praktično in pogost vir napačnih konfiguracij v praksi. Ključno je, da senior inženir ve, da je RBAC le ena plast **obrambe v globino**: privzeto-zavrni **NetworkPolicies**, utrjene nastavitve **securityContext** (non-root, samo bralni korenski datotečni sistem, odvzete zmožnosti (capabilities), seccomp), **Pod Security Admission**, **šifriranje v mirovanju** in zunanji upravitelji za Secrets, skeniranje in podpisovanje slik, admission controllerji (OPA/Gatekeeper, Kyverno) ter zaklenjen dostop do etcd/API — vse to skupaj ščiti gručo. Ker je gruča Kubernetes tarča visoke vrednosti, kjer lahko en sam prekomerno privilegiran ServiceAccount ali odprta NetworkPolicy vodi v popolno ogrozitev, je obvladovanje RBAC in širšega nabora orodij za utrjevanje temeljno za varno upravljanje gruč v produkciji.

Model RBAC

Primer Role + RoleBinding

ServiceAccounti: identiteta za Pode

Obramba v globino — onkraj RBAC

Zakaj je to pomembno

Povezana vprašanja