Kubernetes-Sicherheit für KMU: Container-Orchestrierung richtig absichern

Container haben sich in vielen Unternehmen als Standard für den Betrieb von Anwendungen etabliert – und mit ihnen wächst der Bedarf, mehrere Container koordiniert zu betreiben. Genau dafür setzen immer mehr Betriebe auf Kubernetes. Das Problem: Ein Kubernetes-Cluster ist deutlich komplexer als ein einzelner Docker-Host, und viele KMU übernehmen Standardkonfigurationen, ohne die Sicherheitsimplikationen zu verstehen. Die Folge sind offene Dashboards, überprivilegierte Dienstkonten und Cluster, die aus dem Internet erreichbar sind – ein gefundenes Fressen für Angreifer.

Warum Kubernetes-Sicherheit ein eigenes Thema ist

Ein Kubernetes-Cluster besteht aus vielen beweglichen Teilen: der Control Plane, mehreren Worker-Nodes, dem API-Server, etcd als zentralem Datenspeicher und einem Netzwerk aus Pods, die miteinander kommunizieren. Jede dieser Komponenten kann falsch konfiguriert sein und damit zum Einfallstor werden. Anders als bei einem einzelnen Docker-Container reicht eine einzige Fehlkonfiguration im Cluster oft aus, um sich lateral durch die gesamte Infrastruktur zu bewegen.

Sicherheitsforscher berichten regelmäßig über offen im Internet erreichbare Kubernetes-Dashboards und API-Server ganz ohne Authentifizierung. Wer einen solchen Zugang findet, kann im schlimmsten Fall beliebige Container starten, auf Secrets zugreifen oder den gesamten Cluster für Krypto-Mining kapern. Für ostdeutsche KMU, die zunehmend eigene Anwendungen containerisiert betreiben, ist das kein theoretisches Risiko mehr, sondern eine reale Angriffsfläche.

Die häufigsten Schwachstellen in Kubernetes-Clustern

• Offener API-Server: Der zentrale Steuerungspunkt des Clusters ist ohne Authentifizierung oder mit schwachen Zugangsdaten aus dem Internet erreichbar.
• Fehlendes RBAC: Rollenbasierte Zugriffskontrolle (Role-Based Access Control) ist nicht oder zu großzügig konfiguriert, sodass Dienstkonten mehr Rechte haben als nötig.
• Privilegierte Container: Container laufen mit Root-Rechten oder im privilegierten Modus, obwohl sie diese Rechte nicht benötigen.
• Fehlende Netzwerkrichtlinien: Ohne Network Policies können Pods uneingeschränkt miteinander kommunizieren – ein kompromittierter Container kann sich frei im Cluster bewegen.
• Veraltete Kubernetes-Versionen: Bekannte Sicherheitslücken in älteren Versionen bleiben ungepatcht, weil Updates als riskant für den laufenden Betrieb gelten.
• Secrets im Klartext: Zugangsdaten und API-Schlüssel werden unverschlüsselt in etcd oder direkt in Manifest-Dateien abgelegt.

Praxisteil: Kubernetes-Cluster konkret absichern

1. Zugriff auf den API-Server einschränken

Der API-Server sollte niemals ohne Authentifizierung oder aus dem offenen Internet erreichbar sein. Nutzen Sie ein VPN oder eine Firewall-Regel, die den Zugriff auf bekannte IP-Bereiche beschränkt, und aktivieren Sie eine starke Authentifizierung – idealerweise über OIDC oder Client-Zertifikate statt statischer Tokens.

2. RBAC konsequent umsetzen

Jedes Dienstkonto und jeder Nutzer sollte nur die Rechte erhalten, die für die jeweilige Aufgabe notwendig sind. Vermeiden Sie die Standardrolle cluster-admin für alltägliche Workloads und definieren Sie stattdessen granulare Rollen pro Namespace. Ein regelmäßiger Audit der vergebenen Rollen deckt überflüssige Berechtigungen auf, bevor sie zum Problem werden.

3. Pods ohne Root-Rechte betreiben

Konfigurieren Sie Ihre Pod-Security-Standards so, dass Container standardmäßig ohne Root-Rechte und ohne privilegierten Modus laufen. Kubernetes bietet dafür sogenannte Pod Security Standards, die auf Namespace-Ebene erzwungen werden können und verhindern, dass ein kompromittierter Container Zugriff auf den zugrunde liegenden Host erhält.

4. Netzwerkverkehr zwischen Pods begrenzen

Mit Network Policies lässt sich festlegen, welche Pods überhaupt miteinander kommunizieren dürfen. Eine sinnvolle Grundregel lautet: Standardmäßig ist jede Kommunikation verboten, notwendige Verbindungen werden explizit erlaubt. Das begrenzt den Schaden, falls ein einzelner Container doch einmal kompromittiert wird – ähnlich wie Netzwerksegmentierung im klassischen Firmennetz.

5. Cluster und Images aktuell halten

Kubernetes-Releases bringen regelmäßig Sicherheitskorrekturen. Planen Sie feste Update-Fenster für die Control Plane und die Worker-Nodes ein und scannen Sie Ihre Container-Images vor dem Deployment auf bekannte Schwachstellen. Ein veraltetes Basis-Image kann Sicherheitslücken enthalten, die längst behoben wären.

6. Secrets richtig verwalten

Verzichten Sie darauf, Zugangsdaten direkt in YAML-Dateien oder Umgebungsvariablen zu hinterlegen. Nutzen Sie Kubernetes Secrets in Kombination mit Verschlüsselung im Ruhezustand (Encryption at Rest) oder ein externes Secret-Management-System, das Zugangsdaten kontrolliert bereitstellt.

7. Monitoring und Audit-Logging aktivieren

Aktivieren Sie das Audit-Logging des API-Servers, um nachvollziehen zu können, wer wann welche Aktionen im Cluster durchgeführt hat. In Kombination mit einem zentralen Log-Monitoring lassen sich ungewöhnliche Aktivitäten – etwa das plötzliche Erstellen privilegierter Pods – frühzeitig erkennen.

Kubernetes-Sicherheit ist kein einmaliges Projekt

Anders als bei einer klassischen Server-Härtung reicht es bei Kubernetes nicht, die Konfiguration einmal einzurichten und dann liegen zu lassen. Neue Deployments, wechselnde Teammitglieder und neue Abhängigkeiten verändern die Angriffsfläche ständig. Wer Kubernetes produktiv einsetzt, sollte Sicherheitsprüfungen fest in den Entwicklungsprozess einbauen – von der Image-Erstellung bis zum laufenden Betrieb.

Für kleinere und mittlere Unternehmen in Dresden und Sachsen bedeutet das oft eine Kombination aus DevOps-Know-how und klassischer IT-Sicherheitspraxis, die intern nicht immer in dieser Tiefe vorhanden ist. Genau hier lohnt sich der Blick auf externe Unterstützung, bevor ein offen erreichbarer Cluster zum teuren Sicherheitsvorfall wird.

Sie betreiben Kubernetes und sind unsicher, ob Ihr Cluster sicher konfiguriert ist?

Rexoma unterstützt KMU in Dresden und Sachsen bei der Absicherung von Container- und Kubernetes-Infrastrukturen – von der RBAC-Konfiguration über Netzwerkrichtlinien bis zum laufenden Monitoring. Sprechen Sie uns an, wenn Sie Ihre Container-Umgebung auf den Prüfstand stellen möchten.

FAQ

Brauchen kleinere Unternehmen überhaupt Kubernetes? Nicht jedes KMU benötigt Kubernetes – für einzelne Anwendungen reicht oft ein einfacher Docker-Host. Kubernetes lohnt sich vor allem, wenn mehrere Dienste skaliert, automatisch neu gestartet oder auf mehrere Server verteilt werden müssen.

Reicht eine Firewall vor dem Cluster als Schutz aus? Nein. Eine Firewall schützt den Zugang von außen, aber nicht vor Fehlkonfigurationen innerhalb des Clusters wie fehlendem RBAC oder privilegierten Containern. Beide Schutzebenen ergänzen sich.

Wie oft sollte ein Kubernetes-Cluster aktualisiert werden? Kubernetes veröffentlicht mehrmals jährlich neue Versionen mit Sicherheitskorrekturen. Ein festes Update-Intervall von wenigen Monaten, kombiniert mit sofortigen Patches bei kritischen Lücken, ist empfehlenswert.

Was ist der Unterschied zwischen Docker- und Kubernetes-Sicherheit? Docker-Sicherheit betrifft vor allem den einzelnen Container und Host. Kubernetes-Sicherheit kommt als zusätzliche Ebene hinzu: Zugriffsrechte, Netzwerkkommunikation zwischen Pods und die Absicherung der Control Plane selbst.

Können wir Kubernetes auch On-Premises sicher betreiben, statt in der Cloud? Ja. On-Premises-Kubernetes erfordert zusätzlich eigene Verantwortung für die zugrunde liegende Infrastruktur, ist aber mit den richtigen Maßnahmen genauso absicherbar wie ein Cloud-Cluster.