Docker- und Kubernetes-Sicherheit: Die 10 Risiken

Im Jahr 2026 nutzen 92 % der Unternehmen Container in der Produktion (Datadog 2025). Docker und Kubernetes sind keine aufkommenden Technologien mehr, sie sind kritische Infrastrukturkomponenten. Dennoch bleibt die Sicherheit containerisierter Umgebungen für viele CISOs ein blinder Fleck. Der Sysdig-Bericht 2025 zeigt, dass 87 % der Docker-Images in Produktion mindestens eine hohe oder kritische Schwachstelle enthalten.

Risiko 1: Verwundbare Images

Dies ist das häufigste Risiko. Ein Docker-Image auf Basis eines nicht aktualisierten ubuntu:22.04 enthält dutzende bekannte CVEs. Das offizielle node:18-Image enthält durchschnittlich über 40 Schwachstellen zu jedem Zeitpunkt.

• Abhilfe: Jedes Image mit Trivy oder Grype vor dem Deployment UND zur Laufzeit scannen. Minimale Images verwenden (Alpine, Distroless). Images mindestens monatlich neu bauen.
• ThreatClaw: Der Trivy-Skill scannt automatisch Images in Ihrer Registry und zur Laufzeit mit EPSS-Priorisierung.

Risiko 2: Secrets in Images oder Umgebung

API-Schlüssel, Passwörter und Token, die in Dockerfiles, Umgebungsvariablen oder Image-Layern hartcodiert sind. Trufflehog und Gitleaks finden noch immer Zugangsdaten in 15-20 % der analysierten Repositories.

• Abhilfe: Kubernetes Secrets (verschlüsselt mit KMS), HashiCorp Vault oder AWS Secrets Manager. Niemals Secrets im Image. Multi-Stage-Builds verwenden, um zu verhindern, dass Build-Secrets im finalen Image landen.

Risiko 3: Container-Escape

Ein falsch konfigurierter Container kann einem Angreifer die Flucht zum Host-Knoten ermöglichen. Klassische Vektoren: Mounten des Docker-Sockets (/var/run/docker.sock), --privileged-Modus, übermäßige Linux-Capabilities (CAP_SYS_ADMIN).

• Abhilfe: Niemals --privileged in Produktion. Kein Docker-Socket-Mount. Kubernetes SecurityContext mit runAsNonRoot: true, readOnlyRootFilesystem: true, alle Capabilities droppen.
• ThreatClaw: Der Docker Bench for Security-Skill prüft diese Konfigurationen automatisch gegen CIS-Empfehlungen.

Risiko 4: Image Supply Chain

Ihr Image hängt von 10 Eltern-Images, 50 Systempaketen und 200 Anwendungsabhängigkeiten ab. Eine einzige Backdoor in der Kette und Ihr Container ist kompromittiert. Der XZ-Utils-Angriff (CVE-2024-3094) hat die Realität dieses Risikos gezeigt.

• Abhilfe: SBOM (Software Bill of Materials) mit Syft generieren. Herkunft mit Sigstore/Cosign verifizieren. Private Registry mit Admission-Scanning verwenden.
• ThreatClaw: Der Syft-Skill generiert das SBOM für jedes Image und der Grype-Skill scannt es kontinuierlich gegen neue CVEs.

Risiko 5: Laufzeitsicherheit

Ein Container in Produktion kann über eine Anwendungsschwachstelle kompromittiert werden (SQL-Injection, SSRF, RCE). Image-Scanning erkennt bekannte Schwachstellen, aber nicht die laufende Ausnutzung.

• Abhilfe: Syscall-Monitoring mit Falco, Erkennung abnormaler Prozesse, Alerting bei ungewöhnlichem Container-Verhalten (Reverse Shell, Crypto-Mining).
• ThreatClaw: ML-Verhaltenserkennung gilt auch für Container, Prozess-, Netzwerk- und Filesystem-Baseline pro Container.

Risiko 6: Fehlende Netzwerk-Policies

Standardmäßig können alle Kubernetes-Pods miteinander kommunizieren. Keine Segmentierung, keine Mikro-Segmentierung. Ein Angreifer, der einen Frontend-Pod kompromittiert, kann direkt den Datenbank-Pod erreichen.

• Abhilfe: Kubernetes NetworkPolicies implementieren. Standard-Deny-All, dann explizit die notwendigen Verbindungen freigeben. Kompatibles CNI erforderlich (Calico, Cilium).

Risiko 7: Fehlkonfiguriertes RBAC

Kubernetes RBAC ist mächtig, aber komplex. Klassische Fehler: ClusterRoleBinding mit cluster-admin auf Service-Konten, Wildcards (*) bei Berechtigungen, Standard-ServiceAccounts mit zu vielen Rechten.

• Abhilfe: Prinzip der geringsten Privilegien. RBAC-Bindings regelmäßig auditieren. Tools wie kubiscan oder rakkess verwenden, um effektive Berechtigungen zu visualisieren.

Risiko 8: Unzureichendes Logging und Monitoring

Ohne zentralisierte Logs ist die Untersuchung eines Vorfalls in einem Kubernetes-Cluster nahezu unmöglich. Pods sind vergänglich, wenn sie abstürzen, verschwinden die Logs.

• Abhilfe: Zentralisierter Logging-Stack (EFK/ELK, Loki). Kubernetes-Audit-Logs aktiviert. Ausreichende Aufbewahrung für Forensik (mindestens 90 Tage). Integration mit Ihrem SIEM.

Risiko 9: Regulatorische Nicht-Compliance

Containerisierte Umgebungen müssen die gleichen Anforderungen erfüllen wie der Rest der Infrastruktur: NIS2, DSGVO, PCI DSS, ISO 27001. Aber traditionelle Kontrollen (Server-Agenten, Port-Scanning) funktionieren in einem Kubernetes-Cluster nicht auf die gleiche Weise.

• Abhilfe: Compliance-Kontrollen an das Container-Paradigma anpassen. CIS Kubernetes Benchmark. Admission-Controller (OPA Gatekeeper, Kyverno) zur Durchsetzung von Richtlinien bei der Zulassung.

Risiko 10: Backup und Disaster Recovery

Stateless Workloads sind leicht neu zu erstellen. Persistente Daten (PersistentVolumes, Stateful-Datenbanken) weniger. Ransomware, die die PVs eines Clusters verschlüsselt, kann ebenso verheerend sein wie Ransomware auf einem traditionellen Server.

• Abhilfe: Velero für das Backup von Kubernetes-Ressourcen + PV-Snapshots. Regelmäßige Wiederherstellungstests. Backup außerhalb des Clusters (3-2-1-Regel). Ransomware-Erkennung auf PVs.

ThreatClaw-Skills für Container-Sicherheit

ThreatClaw enthält spezialisierte Skills für Docker- und Kubernetes-Umgebungen:

• Trivy: Image-Scanning (CVEs, Secrets, Misconfigs), Filesystem-Scanning, Kubernetes-Config-Scanning
• Grype: SCA (Software Composition Analysis) der Abhängigkeiten in Images
• Docker Bench for Security: Automatisiertes CIS Docker Benchmark Audit
• Syft: SBOM-Generierung für Supply-Chain-Nachverfolgbarkeit

Diese Skills laufen kontinuierlich. Jedes neue Image, das in die Registry gepusht wird, wird gescannt. Jeder Konfigurationsdrift wird alarmiert. Der CISO hat Echtzeit-Einblick in die Container-Sicherheitslage, kein monatlicher Snapshot.

FAQ

Ist Docker grundsätzlich weniger sicher als eine VM?

Nein, aber das Sicherheitsmodell ist anders. Container teilen sich den Host-Kernel, was die Isolation im Vergleich zu einer VM reduziert. Mit den richtigen Praktiken (seccomp, AppArmor/SELinux, Namespaces, reduzierte Capabilities) bietet ein korrekt konfigurierter Container jedoch eine reduzierte Angriffsfläche. Das Risiko liegt hauptsächlich in der Fehlkonfiguration, nicht in der Technologie selbst.

Sollte ich Images bei jedem Build oder nur in Produktion scannen?

Beides. Das Scannen beim Build (CI/CD-Pipeline) verhindert, dass verwundbare Images die Produktion erreichen. Laufzeit-Scanning erkennt neue CVEs, die nach dem Deployment veröffentlicht werden. Ein Image, das am Tag eins sauber ist, kann am nächsten Tag verwundbar werden, wenn eine neue CVE in einer seiner Abhängigkeiten entdeckt wird.

Ist Kubernetes für kleine Infrastrukturen notwendig?

Nein. Für weniger als 20 Container reichen Docker Compose oder Docker Swarm oft aus. Kubernetes bringt ab 50+ Containern Mehrwert, besonders wenn Sie Auto-Scaling, Rolling Updates und Multi-Node-Orchestrierung benötigen. Die Kubernetes-Komplexität ist ein Kostenfaktor: mehr Angriffsfläche, mehr mögliche Fehlkonfiguration. Wählen Sie die Komplexität, die Sie brauchen, nicht mehr.

Wie sollte ich die Absicherung eines bestehenden Kubernetes-Clusters priorisieren?

In Prioritätsreihenfolge: (1) Alle Produktions-Images mit Trivy scannen, kritische CVEs beheben. (2) Deny-All-NetworkPolicies aktivieren und notwendige Verbindungen freigeben. (3) RBAC auditieren und übermäßige Berechtigungen entfernen. (4) Audit-Logs aktivieren und zentralisieren. (5) Einen Admission-Controller implementieren (Kyverno oder OPA Gatekeeper). ThreatClaw deckt die Schritte 1-4 automatisch ab.