Kubernetes ist der Standard für den Betrieb von Containern geworden – im eigenen Rechenzentrum ebenso wie als verwalteter Dienst in der Public Cloud. Mit der Verbreitung wächst die Angriffsfläche: Ein Cluster bündelt Anwendungen und Zugangsdaten vieler Teams an einem Punkt.
Hinzu kommt, dass viele Voreinstellungen auf reibungslosen Betrieb ausgelegt sind, nicht auf Abschottung. Kubernetes-Sicherheit betrachtet deshalb alle Ebenen des Clusters, vom Container-Image bis zur Netzwerkrichtlinie.
Was ist Kubernetes-Sicherheit?
Der Begriff fasst alle Maßnahmen zusammen, die einen Kubernetes-Cluster und die darauf laufenden Workloads schützen. Als Ordnungsrahmen dient häufig das 4C-Modell mit den Ebenen Cloud, Cluster, Container und Code: Jede Schicht baut auf der darunterliegenden auf, und eine Schwäche weiter unten hebelt Schutzmaßnahmen weiter oben aus. Zentral ist das Verständnis der Standardwerte. Ohne eigene Konfiguration darf jeder Pod mit jedem anderen kommunizieren, Service-Accounts erhalten großzügige Rechte, und Secrets liegen lediglich kodiert statt verschlüsselt vor. Sicherheit entsteht in Kubernetes durch bewusste Entscheidungen, die als Konfiguration im Cluster hinterlegt und fortlaufend geprüft werden. Die Verantwortung verteilt sich auf mehrere Rollen: Plattformteams härten den Cluster und setzen Leitplanken, Anwendungsteams liefern saubere Images und Manifeste.
Die Schutzebenen im Zusammenspiel
Wirksamer Schutz verteilt sich auf mehrere Ebenen, die ineinandergreifen:
- Image-Ebene: Nur geprüfte und signierte Images aus vertrauenswürdigen Registries gelangen in den Cluster. Schwachstellen-Scans laufen in der Build-Pipeline; Admission-Controller setzen diese Regeln beim Deployment durch.
- Pod-Ebene: Security-Kontexte begrenzen, was ein Container darf – keine Root-Prozesse, schreibgeschützte Dateisysteme, keine erweiterten Kernel-Rechte, kein Durchgriff auf den Host. Pod-Security-Standards definieren das Mindestniveau je Namespace.
- Netzwerk-Ebene: NetworkPolicies beschränken den Verkehr auf definierte Beziehungen zwischen Pods und Namespaces. Ohne solche Richtlinien steht im Cluster ein flaches Netz, in dem sich Angreifer frei bewegen.
- RBAC und Zugriffe: Rollenbasierte Rechtevergabe (RBAC) gilt für Menschen und Service-Accounts gleichermaßen. Das Prinzip minimaler Rechte verhindert, dass ein kompromittiertes Konto gleich den gesamten Cluster steuert.
- Secrets-Management: Zugangsdaten liegen verschlüsselt vor und stammen idealerweise aus einem externen Tresor; regelmäßige Rotation begrenzt den Schaden geleakter Schlüssel. Klartext-Secrets in Manifesten oder Repositories sind der häufigste vermeidbare Fehler.
- Steuerungsebene und Audit: Der API-Server gehört hinter strenge Authentifizierung, der etcd-Datenspeicher wird verschlüsselt. Audit-Logs machen jede Änderung am Cluster nachvollziehbar und liefern die Basis für Erkennung.
Warum das Thema wichtig ist
- Konzentrationsrisiko: Ein Cluster betreibt oft Dutzende Anwendungen. Eine einzige Fehlkonfiguration wirkt damit auf viele Dienste gleichzeitig.
- Offene Standardwerte: Wer nichts einschränkt, betreibt weitreichende Kommunikationsfreiheit und großzügige Rechte im Cluster – oft ohne es zu bemerken.
- Hohe Änderungsrate: Deployments verändern den Zustand mehrmals täglich. Schutz muss als Code definiert sein, damit er jede Änderung automatisch übersteht.
- Offene Lieferkette: Basis-Images und Abhängigkeiten stammen aus öffentlichen Quellen und bringen regelmäßig Schwachstellen mit in den Cluster.
- Auditfähigkeit: Nachweise über Härtung und Zugriffskontrolle werden in Prüfungen zunehmend auch für Container-Plattformen verlangt, etwa im Rahmen von NIS-2.
Typische Szenarien
Beim Neuaufbau einer Container-Plattform lassen sich Rechtekonzept, Richtlinien und Pipeline-Prüfungen von Beginn an verankern – deutlich günstiger als jede Nachrüstung. In gewachsenen Clustern beginnt die Arbeit dagegen mit einer Bestandsaufnahme: Welche Workloads laufen privilegiert, welche Kommunikation findet tatsächlich statt, wo liegen Secrets im Klartext? Multi-Tenant-Cluster, die mehrere Teams oder Mandanten teilen, verlangen saubere Trennung über Namespaces, Quoten und Netzwerkrichtlinien. Bei verwalteten Diensten in der Public Cloud übernimmt der Anbieter die Steuerungsebene; die sichere Konfiguration von Workloads und Zugriffen bleibt Kundenaufgabe. Nach einem Sicherheitsvorfall zeigt die Auswertung fast immer auf dieselben Punkte: zu breite Rechte und fehlende Netzwerksegmentierung. Regulierte Branchen bringen zusätzlich Nachweispflichten mit – hier zahlt es sich aus, wenn Richtlinien als Code vorliegen und Prüfberichte ohne manuelle Sammelarbeit entstehen. Den Betrieb gehärteter Plattformen samt Rechtekonzept, Richtliniendurchsetzung und laufender Überwachung übernehmen in der Praxis häufig spezialisierte Dienstleister.
Abgrenzung: NetworkPolicies und Mikrosegmentierung
NetworkPolicies sind das Bordmittel für Segmentierung innerhalb eines Clusters. Sie wirken auf Pod-Ebene, folgen Labels und sind schnell definiert. Ihre Grenzen: Sie enden am Cluster-Rand, zeigen keine tatsächlichen Verkehrsflüsse und verhalten sich je nach eingesetztem Netzwerk-Plugin unterschiedlich. Zero-Trust-Mikrosegmentierung setzt übergreifend an: Sie erfasst Datenflüsse clusterübergreifend, bezieht virtuelle Maschinen und klassische Server ein und setzt einheitliche Richtlinien über die gesamte Umgebung durch. Beide Ansätze ergänzen sich: NetworkPolicies für die Feinsteuerung im Cluster, Mikrosegmentierung für Sichtbarkeit und Kontrolle über alle Plattformen hinweg. Spürbar wird der Unterschied spätestens im Betrieb – eine Richtlinie, die im Cluster korrekt wirkt, läuft am Übergang zu Datenbank-Servern außerhalb des Clusters schnell ins Leere.
Häufige Fragen
Ist ein verwalteter Kubernetes-Dienst automatisch sicher?
Nein. Der Anbieter härtet und betreibt die Steuerungsebene, also API-Server und Datenspeicher. Alles darüber bleibt Kundenaufgabe: Rechtevergabe, Netzwerkrichtlinien, Image-Prüfung, Secrets und die Konfiguration der Workloads. Genau dort entstehen die meisten Vorfälle. Ein verwalteter Dienst senkt den Betriebsaufwand erheblich, ersetzt aber kein eigenes Sicherheitskonzept.
Was sind Pod-Security-Standards?
Kubernetes definiert drei abgestufte Sicherheitsprofile für Pods: privileged ohne Einschränkungen, baseline gegen bekannte Eskalationswege und restricted mit strengen Vorgaben wie dem Verzicht auf Root-Rechte. Die Profile werden je Namespace zugewiesen und beim Deployment durchgesetzt. Empfehlenswert ist restricted als Regelfall; Ausnahmen erhalten einen eigenen Namespace mit dokumentierter Begründung.
Genügen NetworkPolicies als Segmentierung?
Innerhalb eines einzelnen Clusters sind sie das passende Werkzeug für die Feinsteuerung. Sobald mehrere Cluster, virtuelle Maschinen oder klassische Server hinzukommen, entstehen Lücken: NetworkPolicies enden am Cluster-Rand und zeigen keine realen Verkehrsflüsse. Für durchgehende Sichtbarkeit und einheitliche Richtlinien über die gesamte Umgebung braucht es Mikrosegmentierung als übergreifende Schicht.
Wie geht man mit Secrets in Kubernetes richtig um?
Grundregel: keine Zugangsdaten im Klartext in Manifesten oder Repositories. Die Verschlüsselung der Secrets im Cluster-Datenspeicher sollte aktiviert sein; sensible Werte kommen aus einem externen Tresor mit Zugriffskontrolle und Protokollierung. Kurze Gültigkeiten und regelmäßige Rotation begrenzen den Schaden, falls ein Schlüssel doch einmal abfließt.
Womit sollte die Absicherung beginnen?
Mit den Punkten, die Aufwand und Wirkung am besten verbinden: RBAC-Rechte prüfen und reduzieren, Image-Scans in die Pipeline holen, privilegierte Pods identifizieren und die Kommunikation zwischen Namespaces einschränken. Parallel lohnt der Blick auf tatsächliche Datenflüsse, denn er zeigt, welche Verbindungen eine Richtlinie wirklich braucht. Danach folgen Audit-Logging und Secrets-Härtung.