Jak działa RBAC z ServiceAccountami i jak zabezpieczyć klaster Kubernetes?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** rządzi tym, *kto co może zrobić* na API. Uprawnienia są nadawane **podmiotom** (użytkownicy, grupy, **ServiceAccounts**) przez **powiązanie (binding)** ich z **Rolami**, które wyliczają dozwolone czasowniki (verbs) na zasobach. RBAC to jedna warstwa szerszej strategii hartowania klastra.

## Model RBAC

```text
PODMIOT (user / grupa / ServiceAccount)
   │  powiązany przez
   ▼
RoleBinding ───────► Role         (namespaced: uprawnienia w JEDNEJ przestrzeni nazw)
ClusterRoleBinding ► ClusterRole  (ogólnoklastrowe lub wielokrotnego użytku między przestrzeniami)

Role/ClusterRole = zestaw REGUŁ: "te CZASOWNIKI na tych ZASOBACH"
Bindingi są ADDYTYWNE i NIE ma deny — nadajesz tylko to, co potrzebne.
```

## Przykład Role + RoleBinding

```yaml
# Role: dostęp tylko do odczytu do Podów w przestrzeni nazw "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"]
---
# Powiąż tę Role z 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
```

## ServiceAccounts: tożsamość dla Podów

```text
ServiceAccount to TOŻSAMOŚĆ, której Pod używa do rozmowy z API serverem.
  → Każdy Pod dostaje jeden (SA "default" przestrzeni nazw, jeśli nieokreślony).
  → Do Poda montowany jest projektowany token; RBAC decyduje, co ten token może.
Dobra praktyka: daj każdemu workloadowi WŁASNY SA z RBAC o najmniejszych uprawnieniach
i ustaw automountServiceAccountToken: false, gdy Pod nie potrzebuje dostępu do API.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # zrezygnuj, jeśli wywołania API nie są potrzebne
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # uruchamiaj Pody pod tą tożsamością
```

## Obrona wielowarstwowa — poza RBAC

```text
AUTH        → RBAC o najmniejszych uprawnieniach; ServiceAccounts per-workload; audyt dostępu
NETWORK     → NetworkPolicies domyślnie odmawiające (Pody nie rozmawiają, chyba że dozwolone)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, odbierz uprawnienia
              profile seccomp; Pod Security Admission (restricted) do egzekwowania
SECRETS     → szyfrowanie w spoczynku dla etcd; zewnętrzne menedżery sekretów; ciasny RBAC na sekretach
IMAGES      → skanuj obrazy, używaj zaufanych rejestrów, egzekwuj przez admission (np. silniki polityk)
API/etcd    → ogranicz i szyfruj etcd; TLS wszędzie; ogranicz anonimowy i cluster-admin dostęp
SUPPLY CHAIN→ podpisane obrazy, 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          # co może zrobić bieżący użytkownik?
```

## Dlaczego to ważne

Zabezpieczenie klastra to odpowiedzialność seniora, a RBAC z ServiceAccountami to jego fundament, więc zrozumienie obu to niezbędna wiedza o bezpieczeństwie. Model RBAC jest elegancki i wart zinternalizowania: uprawnienia są **czysto addytywne, bez deny**, nadawane przez **powiązanie podmiotów** (użytkowników, grup, a zwłaszcza **ServiceAccountów**) z **Rolami** (namespaced) lub **ClusterRolami** (ogólnoklastrowymi), które wyliczają dozwolone **czasowniki na zasobach** — co oznacza, że dobre bezpieczeństwo bierze się z nadawania tylko tego, czego potrzebuje każdy workload (**najmniejsze uprawnienia**), a nie z polegania na odmowach. Zrozumienie, że **ServiceAccount to tożsamość, której Pod używa do wołania API** — że każdy Pod dostaje token, że SA `default` to powszechna pułapka nadmiernych uprawnień i że powinieneś dać każdemu workloadowi własny SA o najmniejszych uprawnieniach (i wyłączyć automontowanie tokenu, gdy dostęp do API nie jest potrzebny) — jest wprost praktyczne i częste źródło realnych błędnych konfiguracji. Co kluczowe, inżynier senior wie, że RBAC to tylko jedna warstwa **obrony wielowarstwowej**: domyślnie odmawiające **NetworkPolicies**, zahartowane ustawienia **securityContext** (non-root, tylko do odczytu root filesystem, odebrane uprawnienia, seccomp), **Pod Security Admission**, **szyfrowanie w spoczynku** i zewnętrzne menedżery dla Secretów, skanowanie i podpisywanie obrazów, admission controllery (OPA/Gatekeeper, Kyverno) oraz zamknięty dostęp do etcd/API — wszystko to razem chroni klaster. Ponieważ klaster Kubernetes to cel o wysokiej wartości, gdzie pojedynczy nadmiernie uprawniony ServiceAccount lub otwarta NetworkPolicy może prowadzić do pełnego przejęcia, opanowanie RBAC i szerszego zestawu narzędzi hartowania jest fundamentalne dla bezpiecznej obsługi klastrów na produkcji.

Model RBAC

Przykład Role + RoleBinding

ServiceAccounts: tożsamość dla Podów

Obrona wielowarstwowa — poza RBAC

Dlaczego to ważne

Powiązane pytania