Container-Sicherheit in der Praxis: Wie IT-Teams Docker- und Kubernetes-Umgebungen systematisch absichern

Stilisiertes Vorhängeschloss auf blauem Schaltkreismuster als Symbol für IT-Sicherheit

Container-Technologien wie Docker und Kubernetes haben die Art, wie Anwendungen entwickelt und betrieben werden, grundlegend verändert. Doch mit der Verbreitung von Containern wachsen auch die Angriffsflächen. Container-Sicherheit unterscheidet sich von klassischer Server-Sicherheit in wesentlichen Punkten – und erfordert einen eigenen, systematischen Ansatz.

Warum Container-Sicherheit eigene Regeln braucht

Ein klassischer virtueller Server ist ein abgeschlossenes System: Er hat ein eigenes Betriebssystem, eigene Prozesse und einen definierten Sicherheitsperimeter. Container hingegen teilen sich den Kernel des Host-Systems. Ein Angreifer, dem es gelingt, aus einem Container auszubrechen (Container Escape), bewegt sich direkt auf dem Host.

Hinzu kommt die Dynamik moderner Container-Umgebungen: In einem Kubernetes-Cluster laufen Dutzende bis Tausende Pods gleichzeitig, werden gestartet, gestoppt und neu verteilt. Sicherheitsmaßnahmen müssen skalieren und dürfen nicht von manuellen Eingriffen abhängen.

Container-Images absichern: Weniger ist mehr

Die Sicherheit eines Containers beginnt beim Image. Viele Teams setzen auf vollständige Basis-Images wie ubuntu:latest oder debian:latest, weil sie vertraut sind. Diese Images enthalten jedoch Hunderte von Paketen, die für die Anwendung nicht benötigt werden – und damit potenzielle Angriffsflächen.

Empfohlene Praktiken beim Image-Bau:

Minimale Basis-Images: distroless-Images von Google oder Alpine-Varianten enthalten nur das absolut Notwendige. Angriffsflächen werden drastisch reduziert.
Kein Root-Benutzer: Jede Anwendung in einem Container sollte mit einem unprivilegierten Benutzer laufen. Ein Angreifer, der die Anwendung kompromittiert, erlangt so keine Root-Rechte.
Read-only Filesystems: Wo möglich, sollte das Container-Dateisystem als schreibgeschützt eingehängt werden. Schreibzugriff wird nur für explizit definierte Volumes erlaubt.
Multi-Stage Builds: Build-Werkzeuge und Compiler bleiben im Build-Stage und landen nicht im finalen Image. Das Ergebnis ist kleiner und sicherer.
Regelmäßige Image-Rebuilds: Auch ohne Code-Änderungen sollten Images regelmäßig neu gebaut werden, um Patches aus dem Basis-Image zu übernehmen.

Vulnerability Scanning in der CI/CD-Pipeline

Images sollten vor dem Deployment automatisch auf bekannte Schwachstellen geprüft werden. Tools wie Trivy, Grype oder Snyk Container scannen Images auf bekannte CVEs und zeigen, welche Pakete betroffen sind und welche Schwere die jeweilige Schwachstelle hat.

In einer reifen Pipeline wird ein Image mit kritischen oder hochriskanten CVEs gar nicht erst in die Registry gepusht. Weniger kritische Befunde werden dokumentiert und in einem festen Rhythmus behoben. Wichtig ist dabei, Schwachstellen nach Ausnutzbarkeit zu priorisieren – nicht jede theoretisch vorhandene CVE ist im jeweiligen Kontext ausnutzbar.

Kubernetes RBAC richtig konfigurieren

In Kubernetes regelt das Role-Based Access Control-System (RBAC), welche Subjekte – Nutzer, Service Accounts, Gruppen – welche Aktionen auf welchen Ressourcen durchführen dürfen. Eine häufige Fehlkonfiguration ist die Vergabe von Cluster-Admin-Rechten an Service Accounts, die sie nicht benötigen.

Best Practices für Kubernetes RBAC:

Service Accounts erhalten ausschließlich die Rechte, die sie für ihre konkrete Funktion benötigen – nicht mehr.
ClusterRole-Bindungen werden nur dort eingesetzt, wo Namespace-übergreifende Rechte wirklich notwendig sind.
Service Accounts werden pro Anwendung angelegt, nicht geteilt.
Die default-Service-Account-Bindung wird in jedem Namespace explizit eingeschränkt.

Network Policies und Segmentierung

Standardmäßig kann jeder Pod in einem Kubernetes-Cluster mit jedem anderen Pod kommunizieren. Das ist im Sinne von Zero-Trust-Prinzipien problematisch: Ein kompromittierter Pod könnte lateral im Cluster navigieren.

Mit Kubernetes Network Policies wird der Netzwerkverkehr auf Namespace- und Pod-Ebene explizit erlaubt. Alles, was nicht explizit erlaubt ist, wird blockiert. Die Einführung von Network Policies beginnt sinnvollerweise mit einer Default Deny All-Policy für jeden Namespace, gefolgt von gezielten Ausnahmen für tatsächlich benötigte Kommunikationspfade.

Pod Security Standards und Admission Control

Kubernetes bietet mit den Pod Security Standards drei vordefinierte Sicherheitsstufen: Privileged, Baseline und Restricted. Für Produktionsnamespaces gilt als Ziel der Restricted-Standard: kein Root, keine privilegierten Container, read-only Dateisystem und eingeschränkte Capabilities.

Admission Controller wie OPA Gatekeeper oder Kyverno können sicherstellen, dass nur konforme Pod-Definitionen in den Cluster gelangen. Richtlinien werden als Code definiert, versioniert und automatisch durchgesetzt.

Laufzeitschutz mit Falco

Falco ist ein Open-Source-Tool für die Laufzeit-Sicherheit in Container-Umgebungen. Es überwacht System-Calls auf Kernel-Ebene und erkennt verdächtiges Verhalten – etwa wenn ein Container-Prozess plötzlich eine Shell öffnet, auf unerwartete Dateipfade zugreift oder Netzwerkverbindungen zu externen Endpunkten aufbaut.

Falco-Regeln beschreiben erlaubtes Normalverhalten. Abweichungen davon erzeugen Alarme, die an SIEM-Systeme oder Alerting-Pipelines weitergeleitet werden können. Damit wird Laufzeit-Sicherheit zu einem Teil des Monitoring-Stacks.

KI-gestützte Schwachstellenerkennung

Moderne KI-Werkzeuge ergänzen klassische Container-Security-Ansätze. KI-basierte Analysesysteme können ungewöhnliche Kommunikationsmuster innerhalb eines Clusters erkennen, die traditionellen regelbasierten Systemen entgehen. Sie können Cluster-Konfigurationen automatisch auf Fehlkonfigurationen prüfen und Behebungsvorschläge generieren.

Tools wie Kubescape nutzen maschinelles Lernen, um Kubernetes-Konfigurationen gegen bekannte Angriffsmuster und Compliance-Frameworks abzugleichen. Das reduziert den manuellen Aufwand für Sicherheitsreviews erheblich, ohne den menschlichen Entscheidungsprozess zu ersetzen.