Wie funktioniert RBAC mit ServiceAccounts, und wie sicherst du einen Kubernetes-Cluster ab?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** regelt, *wer was* auf der API tun darf. Berechtigungen werden **Subjekten** (Users, Groups, **ServiceAccounts**) gewährt, indem man sie an **Roles** **bindet**, die erlaubte Verbs auf Ressourcen auflisten. RBAC ist eine Ebene einer umfassenderen Cluster-Härtungsstrategie.

## Das RBAC-Modell

```text
SUBJECT (user / group / ServiceAccount)
   │  gebunden durch
   ▼
RoleBinding ───────► Role         (namespaced: Berechtigungen innerhalb EINES Namespace)
ClusterRoleBinding ► ClusterRole  (clusterweit oder namespace-übergreifend wiederverwendbar)

Role/ClusterRole = eine Menge von REGELN: "diese VERBS auf diesen RESSOURCEN"
Bindings sind ADDITIV und es gibt KEIN deny — du gewährst nur, was gebraucht wird.
```

## Beispiel Role + RoleBinding

```yaml
# Eine Role: read-only-Zugriff auf Pods im Namespace "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"]
---
# Diese Role an einen ServiceAccount binden
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: Identität für Pods

```text
Ein ServiceAccount ist die IDENTITÄT, die ein Pod nutzt, um mit dem API-Server zu sprechen.
  → Jeder Pod bekommt einen (den "default"-SA des Namespace, falls nicht angegeben).
  → Ein projected token wird in den Pod gemountet; RBAC entscheidet, was dieses Token darf.
Best Practice: gib jedem Workload seinen EIGENEN SA mit least-privilege RBAC,
und setze automountServiceAccountToken: false, wenn der Pod keinen API-Zugriff braucht.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # abwählen, wenn keine API-Calls nötig
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # Pods unter dieser Identität ausführen
```

## Defense in Depth — über RBAC hinaus

```text
AUTH        → least-privilege RBAC; ServiceAccounts pro Workload; Zugriff auditieren
NETWORK     → default-deny NetworkPolicies (Pods können nicht sprechen, außer erlaubt)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, capabilities droppen
              seccomp profiles; Pod Security Admission (restricted) zum Durchsetzen
SECRETS     → encryption at rest für etcd; externe Secret-Manager; enges RBAC auf Secrets
IMAGES      → Images scannen, vertrauenswürdige Registries nutzen, per Admission durchsetzen (z. B. policy engines)
API/etcd    → etcd einschränken & verschlüsseln; TLS überall; anonymen & cluster-admin-Zugriff begrenzen
SUPPLY CHAIN→ signierte 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          # was darf der aktuelle User tun?
```

## Warum es wichtig ist

Einen Cluster abzusichern ist eine Senior-Verantwortung, und RBAC mit ServiceAccounts ist ihr Fundament, daher ist das Verständnis beider essenzielles Sicherheitswissen. Das RBAC-Modell ist elegant und lohnt sich zu verinnerlichen: Berechtigungen sind **rein additiv ohne deny**, gewährt durch das **Binden von Subjekten** (Users, Groups und besonders **ServiceAccounts**) an **Roles** (namespaced) oder **ClusterRoles** (clusterweit), die erlaubte **Verbs auf Ressourcen** aufzählen — was bedeutet, dass gute Sicherheit daraus entsteht, nur zu gewähren, was jeder Workload braucht (**least privilege**), statt sich auf Verweigerungen zu verlassen. Zu verstehen, dass ein **ServiceAccount die Identität ist, die ein Pod nutzt, um die API aufzurufen** — dass jeder Pod ein Token bekommt, dass der `default`-SA eine häufige Over-Privilege-Falle ist und dass du jedem Workload seinen eigenen least-privilege-SA geben solltest (und das automatische Mounten des Tokens deaktivieren, wenn kein API-Zugriff nötig ist) — ist direkt praktisch und eine häufige Quelle realer Fehlkonfiguration. Entscheidend ist, dass ein Senior-Ingenieur weiß, dass RBAC nur eine Ebene von **defense in depth** ist: default-deny **NetworkPolicies**, gehärtete **securityContext**-Einstellungen (non-root, read-only root filesystem, gedroppte capabilities, seccomp), **Pod Security Admission**, **encryption at rest** und externe Manager für Secrets, Image-Scanning und -Signierung, admission controllers (OPA/Gatekeeper, Kyverno) und abgeschotteter etcd/API-Zugriff kombinieren sich, um einen Cluster zu schützen. Weil ein Kubernetes-Cluster ein hochwertiges Ziel ist, bei dem ein einziger überberechtigter ServiceAccount oder eine offene NetworkPolicy zu vollständiger Kompromittierung führen kann, ist die Beherrschung von RBAC und des umfassenderen Härtungswerkzeugkastens grundlegend, um Cluster in Produktion sicher zu betreiben.

Das RBAC-Modell

Beispiel Role + RoleBinding

ServiceAccounts: Identität für Pods

Defense in Depth — über RBAC hinaus

Warum es wichtig ist

Ähnliche Fragen