Datensicherheit in Kubernetes: RBAC, Secrets und Network Policies

Kubernetes vereinfacht den Betrieb verteilter Anwendungen — schafft aber gleichzeitig eine Angriffsfläche, die viele Teams unterschätzen. Default-Konfigurationen sind selten produktionsreif: Pods laufen mit zu vielen Rechten, Secrets liegen unverschlüsselt im etcd, und Netzwerkverkehr zwischen Diensten ist vollständig offen. Dieser Artikel zeigt die drei Kernbereiche der Datensicherheit in Kubernetes und was konkret zu tun ist.

Warum Default-Kubernetes-Konfigurationen ein Sicherheitsrisiko sind

Ein frisch aufgesetzter Kubernetes-Cluster ist nicht sicher — er ist funktionsfähig. Ohne explizite Konfiguration gilt: Jeder Pod im Cluster kann andere Pods erreichen. Jeder Service Account hat Leserechte auf die Kubernetes-API. Secrets sind base64-kodiert im etcd gespeichert, aber nicht verschlüsselt. Diese Defaults existieren aus Kompatibilitätsgründen, nicht aus Sicherheitsüberlegungen. Für Produktionsumgebungen — insbesondere unter DSGVO-Anforderungen — reichen sie nicht aus.

Die gute Nachricht: Kubernetes bietet alle notwendigen Mechanismen, um Cluster systematisch abzusichern. Es braucht Konzept, keine neuen Tools.

RBAC: Wer darf was im Cluster?

Role-Based Access Control (RBAC) ist das Fundament der Zugriffskontrolle in Kubernetes. Es regelt, welche Subjekte — Nutzer, Gruppen, Service Accounts — welche Operationen auf welchen Ressourcen ausführen dürfen.

Das Grundprinzip: Least Privilege. Jeder Service Account erhält genau die Rechte, die er für seine Aufgabe braucht — nicht mehr. In der Praxis bedeutet das:

• ClusterRoles nur für cluster-weite Ressourcen (Nodes, PersistentVolumes, Namespaces). Alles andere über namespaced Roles.
• Keine Nutzung von cluster-admin für Anwendungs-Service-Accounts.cluster-admin gehört ausschließlich in CI/CD-Pipelines mit kurzlebigen Tokens oder in Break-Glass-Szenarien.
• Regelmäßige Audits der RoleBindings: kubectl get rolebindings,clusterrolebindings -A gibt einen Überblick — ungewöhnlich breite Bindungen fallen sofort auf.

Secrets Management: base64 ist keine Verschlüsselung

Kubernetes Secrets werden standardmäßig unverschlüsselt im etcd gespeichert. Wer Zugriff auf den etcd-Datenspeicher hat — direkt oder über ein etcd-Backup — kann alle Secrets im Klartext lesen. Das ist kein theoretisches Risiko: etcd-Backups landen häufig in S3-Buckets mit unzureichenden Berechtigungen.

Encryption at Rest ist der erste Schritt: Der API-Server unterstützt native etcd-Verschlüsselung über --encryption-provider-config. Provider wie aescbc oder aesgcm verschlüsseln Secrets vor dem Schreiben in etcd. Managed-Kubernetes-Dienste (EKS, GKE, AKS) bieten dies oft über KMS-Integration an.

Für höhere Anforderungen empfiehlt sich ein externes Secrets-Management:

• External Secrets Operator synchronisiert Secrets aus AWS Secrets Manager, Azure Key Vault oder HashiCorp Vault in Kubernetes-Secrets. Die Anwendung greift weiterhin auf natives Kubernetes-API zu — ohne Vault-SDK.
• Sealed Secrets (Bitnami) verschlüsselt Secrets mit einem cluster-spezifischen Key, sodass sie sicher in Git gespeichert werden können. Gut geeignet für GitOps-Workflows.
• Vault Agent Injector injiziert Secrets als Dateien in Pod-Filesysteme — nie als Umgebungsvariablen. Umgebungsvariablen erscheinen in Prozess-Listings und Crash-Dumps.

Network Policies: Mikrosegmentierung im Cluster

Ohne Network Policies ist ein Kubernetes-Cluster intern flach: Jeder Pod kann jeden anderen Pod auf jedem Port erreichen. Im Falle einer kompromittierten Anwendung — etwa durch eine RCE-Schwachstelle — kann ein Angreifer sich lateral durch den gesamten Cluster bewegen.

Network Policies definieren, welcher Ingress- und Egress-Traffic für Pods erlaubt ist. Das CNI-Plugin muss sie unterstützen — Flannel tut es nicht, Calico, Cilium und Weave schon. Eine sinnvolle Baseline:

• Default-Deny in jedem Namespace: Eine Policy, die allen Ingress- und Egress-Traffic blockiert, als Ausgangspunkt. Danach explizit erlauben, was gebraucht wird.
• Namespace-Isolation: Produktions-, Staging- und Entwicklungs-Namespaces kommunizieren nicht miteinander — außer über explizit definierte Gateways oder APIs.
• Egress-Kontrolle: Datenbank-Pods sollten nur mit definierten Anwendungs-Pods kommunizieren dürfen, nicht mit dem Internet. Egress-Policies verhindern Data Exfiltration nach einer Kompromittierung.

Cilium bietet über Network Policies hinaus L7-Visibility (HTTP, gRPC, DNS) und Netzwerk-Policy-Enforcement mit Identitäten statt IPs — deutlich robuster in dynamischen Umgebungen, in denen Pod-IPs sich ständig ändern.

Pod Security: Admission Control als letzte Verteidigungslinie

Seit Kubernetes 1.25 ist PodSecurityPolicy deprecated und durch den Pod Security Admission Controller (PSA) ersetzt. PSA erzwingt Sicherheitsstandards auf Namespace-Ebene mit drei Profilen:

• Privileged: Keine Einschränkungen. Nur für System-Namespaces wie kube-system.
• Baseline: Blockiert die offensichtlichsten Risiken (privileged Containers, hostNetwork, hostPID). Guter Ausgangspunkt für Anwendungs-Namespaces.
• Restricted: Strengste Einstellungen. Erfordert non-root User, read-only Root Filesystem, keine Capabilities. Empfohlen für alle produktiven Workloads.

Für feingranulare Policy-Kontrolle, die über PSA hinausgeht, ist Kyverno die empfohlene Lösung im CNCF-Ökosystem. Kyverno erlaubt Policies als Kubernetes-native YAML-Ressourcen — kein Rego, keine OPA-Lernkurve. Damit lassen sich Anforderungen wie "alle Images müssen aus der eigenen Registry kommen" oder "Labels für Cost-Center sind Pflicht" als ClusterPolicy durchsetzen.

Supply Chain Security: Images und deren Herkunft

Ein oft vernachlässigter Aspekt der Datensicherheit in Kubernetes ist die Container-Image-Supply-Chain. Kompromittierte Images aus öffentlichen Registries — DockerHub, GitHub Container Registry — sind ein realer Angriffsvektor. Maßnahmen:

• Image Scanning: Trivy oder Grype in der CI/CD-Pipeline als Pflicht-Gate. Kein Deployment bei kritischen CVEs ohne explizite Ausnahme.
• Private Registry: Alle produktiven Images aus einer internen Registry (Harbor, AWS ECR, Azure ACR). Kyverno erzwingt die Herkunft per Policy.
• Image Signing: Cosign (Sigstore) signiert Images kryptografisch. Policy Admission Controller überprüfen Signaturen vor dem Start. Damit ist sichergestellt, dass nur Images deployed werden, die die CI/CD-Pipeline durchlaufen haben.
• Immutable Tags: Niemals :latest in Produktion. SHA-basierte Image-Referenzen garantieren Reproduzierbarkeit und verhindern stille Image-Austausche.

DSGVO-Relevanz: Was Kubernetes-Sicherheit rechtlich bedeutet

Für Unternehmen unter DSGVO-Anforderungen — also praktisch alle deutschen Unternehmen — ist Kubernetes-Sicherheit kein optionales Add-on. Art. 32 DSGVO fordert "geeignete technische Maßnahmen" zum Schutz personenbezogener Daten. In einer Kubernetes-Umgebung bedeutet das konkret:

• Verschlüsselung personenbezogener Daten at rest (etcd-Verschlüsselung) und in transit (mTLS via Istio oder Cilium).
• Nachvollziehbare Zugriffskontrolle auf Pods und Daten (RBAC + Audit-Logs).
• Netzwerksegmentierung, die verhindert, dass Anwendungen ohne Personenbezug auf DSGVO-relevante Daten zugreifen.
• Dokumentation der Maßnahmen — Kubernetes Audit-Logs müssen für mindestens 6 Monate archiviert werden.

Ein Security-Audit des Clusters schafft hier Klarheit: Was ist bereits umgesetzt? Was fehlt? Wo sind die größten Risiken?

Fazit: Sicherheit in Kubernetes ist kein Einmal-Projekt

RBAC, Secrets Management, Network Policies und Pod Security sind keine voneinander unabhängigen Maßnahmen — sie greifen ineinander. Ein Cluster, der RBAC korrekt konfiguriert hat, aber Secrets unverschlüsselt im etcd speichert, ist nicht sicher. Ein Cluster mit starken Network Policies, aber ohne Image Signing, ist angreifbar über die Supply Chain.

Datensicherheit in Kubernetes ist ein kontinuierlicher Prozess: neue Workloads bringen neue Anforderungen, neue CVEs erfordern schnelle Reaktion, und regulatorische Vorgaben entwickeln sich weiter. Teams, die diesen Prozess strukturiert aufgesetzt haben, reagieren schneller — und schlafen besser.

Mehr erfahren: Kubernetes-Beratung oder direkt einen Cluster-Audit buchen — wir analysieren Ihren Ist-Zustand und liefern einen priorisierten Maßnahmenplan.