Kubernetes RBAC & Datensicherheit: Was Mittelstand-Teams wissen müssen

Kubernetes vereinfacht den Betrieb von Applikationen — aber ein falsch konfigurierter Cluster ist ein offenes Scheunentor. Für Unternehmen im DACH-Raum, die unter DSGVO-Pflichten arbeiten, ist Datensicherheit in Kubernetes kein optionales Feature, sondern eine Grundanforderung. Dieser Artikel zeigt, welche Mechanismen wirklich zählen und wo die häufigsten Lücken entstehen.

Warum Kubernetes-Sicherheit anders funktioniert als klassische Server-Sicherheit

Traditionelle Sicherheitskonzepte denken in Perimetern: Firewall außen, Vertrauen innen. Kubernetes bricht dieses Modell auf. Hunderte Pods kommunizieren cluster-intern, Service Accounts erhalten implizit Berechtigungen, und ein einziger kompromittierter Container kann lateral durch den gesamten Cluster bewegen. Die Angriffsfläche ist grundlegend anders — und sie wächst mit jeder neuen Workload.

Das bedeutet: Sicherheit muss auf mehreren Ebenen gleichzeitig greifen. RBAC regelt, wer was darf. Network Policies begrenzen, wer mit wem spricht. Secrets-Management schützt Zugangsdaten. Pod Security kontrolliert, was ein Container überhaupt ausführen darf. Wer nur eine Ebene absichert, hat ein falsches Sicherheitsgefühl.

RBAC: Die erste Verteidigungslinie

Role-Based Access Control (RBAC) ist seit Kubernetes 1.8 standardmäßig aktiviert — aber aktiviert bedeutet nicht richtig konfiguriert. In der Praxis sehen wir regelmäßig drei Antipatterns:

• Wildcard-Berechtigungen: verbs: ["*"] aufresources: ["*"] — oft in initialen Cluster-Setups, die nie bereinigt wurden.
• Cluster-weite Rollen statt Namespace-Rollen: Ein Team braucht Deployment-Rechte in einem Namespace, bekommt aber eine ClusterRole, die den gesamten Cluster betrifft.
• Default Service Accounts mit zu vielen Rechten: Pods laufen ohne explizite Service Account-Konfiguration und erben dabei mehr Berechtigungen als notwendig.

Das Least-Privilege-Prinzip klingt trivial, ist in der Praxis aber aufwendig — vor allem wenn Anwendungen historisch gewachsen sind und niemand mehr genau weiß, welche RBAC-Regeln welcher Workload wirklich braucht.

Network Policies: Segmentierung innerhalb des Clusters

Ohne Network Policies können alle Pods in einem Cluster miteinander kommunizieren — unabhängig von Namespace oder Team-Zugehörigkeit. Das ist der Kubernetes-Standard. Für produktive Workloads ist das inakzeptabel.

Network Policies definieren auf Label-Basis, welche Pods eingehenden und ausgehenden Traffic erlauben. Eine gute Ausgangsbasis ist ein Default-Deny-All pro Namespace, kombiniert mit expliziten Erlaubnisregeln für bekannte Kommunikationspfade:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Wichtig: Network Policies sind ein API-Objekt von Kubernetes, werden aber durch das CNI-Plugin (z.B. Cilium, Calico, Weave) tatsächlich durchgesetzt. Ohne ein kompatibles CNI existieren Network Policy-Objekte im Cluster, haben aber keinerlei Wirkung. Wer auf AWS EKS mit dem Standard-VPC-CNI arbeitet, muss zusätzlich den Network Policy Controller aktivieren.

Secrets-Management: Das unterschätzte Risiko

Kubernetes Secrets sind standardmäßig Base64-kodiert — das ist keine Verschlüsselung. Wer etcd nicht mit Encryption at Rest konfiguriert hat, speichert Datenbankpasswörter und API-Keys im Klartext auf Disk. Gleichzeitig werden Secrets häufig als Umgebungsvariablen in Pods injiziert, wo sie in Process-Listen sichtbar sind.

Für produktive Umgebungen empfehlen sich externe Secrets-Lösungen. Die gängigsten Optionen im DACH-Umfeld:

• External Secrets Operator (ESO) mit AWS Secrets Manager, Azure Key Vault oder HashiCorp Vault als Backend — synchronisiert Secrets in native Kubernetes-Objekte, ohne dass Teams Vault-Zugriff brauchen.
• Sealed Secrets von Bitnami — verschlüsselt Secrets clientseitig, sodass sie sicher in Git gespeichert werden können. Gut kombinierbar mit GitOps-Workflows.
• CSI Secrets Store Driver — mountet Secrets direkt als Volumes aus einem externen Store, ohne sie als Kubernetes-Secret-Objekte zu persistieren.

Pod Security: Was Container tun dürfen

Selbst mit korrektem RBAC und Network Policies kann ein Container mitsecurityContext.privileged: true den Host-Kernel direkt ansprechen und alle anderen Sicherheitsmaßnahmen unterlaufen. Pod Security Standards (PSS) — seit Kubernetes 1.25 der Nachfolger der deprecated Pod Security Policies — definieren drei Sicherheitsniveaus:

• Privileged: Keine Einschränkungen. Nur für System-Workloads (z.B. CNI-Plugins).
• Baseline: Verhindert bekannte Privilege-Escalation-Vektoren. Geeignet für die meisten Applikationen.
• Restricted: Stark eingeschränkt, folgt aktuellen Best Practices. Ziel für produktive Applikationen.

Die Standards werden per Namespace-Label aktiviert und durch den integrierten Pod Security Admission Controller durchgesetzt. Für granularere, policy-as-code-basierte Kontrolle bietet sich Kyverno an, das deutlich flexibler ist als die eingebauten Standards.

Audit Logging: Nachvollziehbarkeit für DSGVO-Anforderungen

Für Unternehmen unter DSGVO-Pflichten ist Audit Logging nicht optional. Der Kubernetes API-Server kann so konfiguriert werden, dass alle Lese- und Schreiboperationen auf sensitiven Ressourcen protokolliert werden. Eine Audit Policy definiert dabei granular, welche Requests in welchem Detail geloggt werden.

Typische Ressourcen, die immer geloggt werden sollten: Secrets, ConfigMaps, ServiceAccounts, RoleBindings, ClusterRoleBindings. Die Logs müssen in einem tamper-proof Storage landen — nicht im selben Cluster, den sie überwachen. Tools wie Falco ermöglichen darüber hinaus Echtzeit-Erkennung von verdächtigem Verhalten auf Syscall-Ebene.

Security als kontinuierlicher Prozess, nicht als Einmalprojekt

Die größte Schwäche in Kubernetes-Sicherheitskonzepten ist nicht fehlendes Wissen über einzelne Mechanismen — es ist das Fehlen eines kontinuierlichen Prozesses. RBAC-Regeln veralten, wenn Teams wechseln. Network Policies decken neue Services nicht ab, wenn sie ohne Security-Review ausgerollt werden. Container-Images akkumulieren CVEs.

Ein funktionierendes Security-Konzept braucht: regelmäßige RBAC-Reviews, automatisiertes Image-Scanning in der CI/CD-Pipeline, Network-Policy-Tests als Teil des Deployments und klare Verantwortlichkeiten im Team. Das lässt sich nicht einmalig einrichten und dann vergessen.

Fazit: Sicherheit braucht Tiefe, nicht nur Breite

RBAC, Network Policies, Secrets-Management, Pod Security und Audit Logging sind keine isolierten Features — sie bilden zusammen ein Sicherheitsmodell, das nur funktioniert, wenn alle Schichten greifen. Wer einen Layer ausspart, hat Lücken, die ein Angreifer (oder ein DSGVO-Prüfer) findet.

Für Mittelstandsteams, die ihren Cluster gezielt auf Sicherheitslücken prüfen lassen wollen, ohne monatelange Beratungsprojekte zu starten, bietet sich ein strukturierter Einstieg an.

Mehr erfahren: Kubernetes-Beratung oder Audit buchen.