Datensicherheit in Kubernetes: RBAC, Network Policies und Pod Security

Kubernetes ist standardmäßig nicht sicher konfiguriert. Ein frisch aufgesetzter Cluster erlaubt Pods mit Root-Rechten, hat keine Netzwerktrennung zwischen Namespaces und vergibt implizit weitreichende API-Zugriffe. Für Unternehmen im DACH-Raum, die unter DSGVO-Anforderungen arbeiten, ist das kein akzeptabler Zustand. Dieser Beitrag zeigt, welche drei Schichten der Datensicherheit in Kubernetes tatsächlich relevant sind — und was bei jeder Schicht konkret zu tun ist.

Schicht 1: Zugriffskontrolle mit RBAC

Role-Based Access Control (RBAC) ist das zentrale Berechtigungsmodell in Kubernetes. Es regelt, welche Principals (ServiceAccounts, User, Groups) welche Verben (get, list, watch, create, delete, …) auf welche Ressourcen anwenden dürfen.

Das häufigste Problem in der Praxis: Teams vergeben cluster-admin pauschal an CI/CD-ServiceAccounts oder an alle Entwickler, weil das initiale Setup schneller geht. Das Ergebnis ist ein flaches Berechtigungsmodell ohne Isolation.

Eine sinnvolle RBAC-Struktur folgt dem Least-Privilege-Prinzip:

• Namespace-Scope bevorzugen: Role und RoleBinding statt ClusterRole und ClusterRoleBinding, wo immer möglich.
• ServiceAccounts je Workload: Jede Applikation erhält einen eigenen ServiceAccount — nicht den default-Account des Namespace.
• Token-Automount deaktivieren: automountServiceAccountToken: false in der Pod-Spec, wenn die Applikation die Kubernetes-API nicht benötigt.
• Aggregierte ClusterRoles nutzen: Statt monolithischer Rollen schichten Sie granulare Rollen über Labels auf.

Schicht 2: Netzwerktrennung mit Network Policies

Ohne Network Policies kommunizieren alle Pods in einem Cluster uneingeschränkt miteinander — unabhängig vom Namespace. Ein kompromittierter Pod in der staging-Umgebung kann direkt auf Dienste in production zugreifen.

Network Policies sind namespacegebundene Ressourcen, die Ingress- und Egress-Traffic auf Pod-Ebene steuern. Sie wirken additiv: Sobald eine Policy auf einen Pod selektiert, wird aller nicht explizit erlaubter Traffic geblockt.

Eine bewährte Grundstruktur:

• Default-Deny pro Namespace: Eine leere NetworkPolicy mit leerem podSelector und ohne ingress/egress-Regeln blockt allen Traffic als Ausgangspunkt.
• Explizite Freigaben: Nur die tatsächlich benötigten Kommunikationspfade werden per Policy freigegeben — z. B. Frontend → Backend, Backend → Datenbank.
• Namespace-Isolation: namespaceSelector stellt sicher, dass Namespace-übergreifende Verbindungen nur dort erlaubt sind, wo sie fachlich notwendig sind (z. B. Monitoring-Namespace → alle Workloads).

Wichtig: Network Policies sind eine CNI-Funktion. Sie benötigen ein kompatibles CNI-Plugin — Flannel allein reicht nicht. Cilium, Calico und Weave Net setzen Network Policies vollständig um.

Schicht 3: Pod Security Standards

Pod Security Standards (PSS) lösen seit Kubernetes 1.25 die veralteten PodSecurityPolicies ab. Sie definieren drei Sicherheitsstufen:

• Privileged: Keine Einschränkungen — nur für System-Komponenten geeignet (z. B. CNI-Plugins).
• Baseline: Blockiert bekannte Privilege-Escalation-Pfade. Geeignet für die meisten Anwendungs-Workloads.
• Restricted: Erzwingt Best Practices, darunter Non-Root-User, Read-only-Root-Filesystem und das Verbot privilegierter Capabilities. Für sicherheitskritische Workloads.

PSS werden per Namespace-Label aktiviert:

kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted

Der warn-Modus ist besonders nützlich für bestehende Cluster: Er blockiert noch keine Pods, gibt aber direkte Hinweise imkubectl apply-Output, wenn eine Pod-Spec den Standard verletzt.

Supply-Chain-Sicherheit: Images und Secrets

Netzwerk- und Laufzeitsicherheit greifen zu spät, wenn das Container-Image selbst kompromittiert ist. Zwei Maßnahmen sind hier besonders wirkungsvoll:

• Image-Signaturen: Mit Cosign (Sigstore) signieren Sie Images nach dem Build und verifizieren die Signatur per Admission-Controller vor dem Deployment. So schließen Sie aus, dass unsignierte oder manipulierte Images in den Cluster gelangen.
• Secret-Management: Kubernetes-Secrets sind Base64-kodiert, nicht verschlüsselt. Für produktive Umgebungen empfehlen sich External Secrets Operator (ESO) in Verbindung mit einem externen Secrets-Backend (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). Alternativ: Sealed Secrets für GitOps-Workflows.

Audit-Logging und Laufzeit-Erkennung

Präventive Maßnahmen decken bekannte Angriffsmuster ab. Laufzeit-Erkennung ist notwendig, um unbekannte Muster zu erkennen. Falco ist hier der De-facto-Standard im Kubernetes-Ökosystem: Es analysiert Kernel-Syscalls in Echtzeit und schlägt Alarm, wenn ein Pod unerwartete Aktionen ausführt — z. B. Shell-Aufruf aus einem Webserver-Prozess, Schreiben in /etc/passwd oder Netzwerkverbindungen auf unbekannte IPs.

Ergänzend dazu sollte das Kubernetes-API-Audit-Logging aktiviert sein. Es protokolliert alle API-Anfragen mit Caller-Information und ermöglicht die Nachverfolgung von Konfigurationsänderungen — relevant für DSGVO-Nachweispflichten und interne Compliance-Anforderungen.

Fazit: Sicherheit ist kein Einmalereignis

Datensicherheit in Kubernetes entsteht nicht durch ein einzelnes Tool, sondern durch das Zusammenspiel mehrerer Schichten: Zugriffssteuerung (RBAC), Netzwerktrennung (Network Policies), Laufzeitbeschränkungen (Pod Security Standards), sichere Supply Chain und kontinuierliche Erkennung (Falco, Audit-Logs). Jede dieser Schichten adressiert einen anderen Angriffspfad.

Für Mittelstandsunternehmen mit begrenzten Plattform-Kapazitäten ist ein strukturierter Einstieg entscheidend: Nicht alle Maßnahmen gleichzeitig, sondern priorisiert nach Risikoprofil und bestehender Infrastruktur.

Wenn Sie wissen möchten, wo Ihr Cluster heute steht, ist ein strukturierter Review der richtige erste Schritt. Mehr dazu unter Kubernetes-Beratung oder direkt zum Audit buchen.