Container-Security: Docker, Kubernetes und Image-Scans für KMU

Key Takeaways

• Container ohne Härtung sind ein verbreitetes Einfallstor – auch in KMU-Umgebungen
• Trivy scannt Docker-Images in Sekunden auf bekannte CVEs und Fehlkonfigurationen
• Kubernetes-Cluster brauchen eigene Security-Policies, unabhängig von der Cloud-Plattform
• NIS-2 und DSGVO verlangen nachweisbare technische Schutzmaßnahmen – Image-Scanning zählt dazu
• Wazuh lässt sich direkt in Container-Umgebungen integrieren und erkennt Laufzeit-Anomalien

Warum Container-Security kein Thema nur für Konzerne ist

Container haben sich auch im Mittelstand durchgesetzt. Wer Web-Applikationen, Microservices oder interne Tools mit Docker betreibt und erste Schritte mit Kubernetes unternommen hat, hat gleichzeitig eine neue Angriffsfläche geschaffen – oft ohne es zu merken.

Das Grundproblem: Ein Container ist keine virtuelle Maschine. Er teilt sich den Kernel mit dem Host-System. Ein kompromittierter Container kann unter Umständen auf andere Container, auf Mount-Points oder direkt auf den Host zugreifen. Und da viele Docker-Images von Docker Hub stammen, öffentlich gebaut und nicht geprüft sind, schleppt man mit jedem docker pull potenzielle Schwachstellen ins eigene Netz.

Für KMU ohne eigenes Security-Team ist das besonders kritisch: Es gibt keine automatische Prüfung, keine zentrale Image-Registry mit Scan-Funktion, und Images werden oft jahrelang nicht aktualisiert. Das Ergebnis sind produktive Systeme mit hunderten bekannter Schwachstellen – dokumentiert in öffentlichen CVE-Datenbanken, zugänglich für jeden Angreifer.

Was Container-Umgebungen konkret bedroht

Verwundbare Base-Images

Die meisten Images basieren auf Linux-Distributionen wie Debian, Ubuntu oder Alpine. Diese enthalten Bibliotheken und Pakete mit bekannten CVEs (Common Vulnerabilities and Exposures). Wenn ein Image einmal gebaut und deployed wurde, wird es selten aktualisiert.

Ein konkretes Beispiel: Das offizielle node:18 Image kann je nach Build-Zeitpunkt Dutzende von CVEs enthalten, darunter kritische mit CVSS-Score über 9.0. Wer dieses Image vor zwölf Monaten gebaut und seitdem nicht aktualisiert hat, betreibt verwundbare Software – dokumentiert, bekannt, ausnutzbar.

Falsch konfigurierte Container

Häufige Fehler in der Praxis, die in Security-Audits immer wieder auftauchen:

• Container laufen als root, obwohl das nicht notwendig ist
• Datenbankpasswörter und API-Keys landen als Klartext in docker-compose.yml oder direkt im Image
• Unnötige Ports werden nach außen exponiert
• Das --privileged-Flag wird gesetzt, ohne dass ein legitimer Grund vorliegt
• Resource-Limits fehlen komplett, was DoS-Angriffe von innen ermöglicht

Supply-Chain-Angriffe

Ein Angreifer, der ein populäres Public-Image auf Docker Hub manipuliert, kann Tausende von Deployments kompromittieren. Solche Vorfälle sind dokumentiert. Wer Images nicht selbst baut, aus vertrauenswürdigen Quellen bezieht und kryptografisch verifiziert, vertraut blind auf fremde Infrastruktur.

Kubernetes-spezifische Risiken

Kubernetes bringt eine eigene Angriffsfläche:

• Fehlkonfigurierte RBAC-Regeln erlauben zu weitreichende Zugriffsrechte auf den API-Server
• Kubernetes Secrets werden standardmäßig nur Base64-kodiert in etcd gespeichert – das ist keine Verschlüsselung
• Fehlende Network Policies erlauben freie Kommunikation zwischen allen Pods
• Der API-Server ist in manchen Cloud-Setups ohne Einschränkung aus dem Internet erreichbar

Image-Scanning mit Trivy: Praxis-Einstieg

Trivy ist ein Open-Source-Scanner von Aqua Security, der Images, Filesysteme, Git-Repositories und Kubernetes-Manifeste auf Schwachstellen und Fehlkonfigurationen prüft. Die Installation ist in wenigen Minuten erledigt, die Integration in bestehende CI/CD-Pipelines unkompliziert.

Installation und erster Scan

# Installation unter Debian/Ubuntu
sudo apt-get install wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main \
  | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update && sudo apt-get install trivy

# Einfacher Image-Scan
trivy image nginx:latest

Die Ausgabe listet alle gefundenen CVEs nach Schweregrad (CRITICAL, HIGH, MEDIUM, LOW) und zeigt, ob bereits ein Fix verfügbar ist. Das ist der erste entscheidende Filter: fixable vs. unfixable.

Integration in CI/CD mit Threshold

# Build schlägt fehl, wenn CRITICAL-Schwachstellen gefunden werden
trivy image --exit-code 1 --severity CRITICAL myapp:latest

# Nur behebbare Schwachstellen anzeigen, ab HIGH
trivy image --ignore-unfixed --severity HIGH,CRITICAL myapp:latest

# SARIF-Output für Azure DevOps / GitHub Security Tab
trivy image --format sarif --output trivy-results.sarif myapp:latest

Dieses Muster lässt sich direkt in GitHub Actions, GitLab CI oder Azure DevOps einbauen. Kein Image mit kritischen, behebbaren Schwachstellen gelangt in die Produktion.

Kubernetes-Cluster scannen

# Cluster-weiter Überblick
trivy k8s --report=summary cluster

# Einzelnen Namespace detailliert prüfen
trivy k8s --namespace production --report=all cluster

Trivy prüft dabei nicht nur Images, sondern auch Kubernetes-Manifeste auf Fehlkonfigurationen – fehlende securityContext-Definitionen, zu weitreichende RBAC-Regeln oder Pods ohne Resource-Limits.

Docker-Härtung: Die wichtigsten Maßnahmen

1. Non-Root-User im Container

Prozesse als root zu betreiben ist in Containern vermeidbar und sollte es auch sein. Ein Angreifer, der einen RCE-Bug in der Applikation ausnutzt, erhält sonst automatisch root-Rechte im Container.

FROM node:18-alpine

# Dedizierten Applikations-User anlegen
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

WORKDIR /app
COPY --chown=appuser:appgroup . .
RUN npm ci --only=production

# Als non-root User ausführen
USER appuser

EXPOSE 3000
CMD ["node", "server.js"]

2. Minimale Base-Images

Alpine-Linux-basierte Images haben eine deutlich kleinere Angriffsfläche als Debian-basierte. Distroless-Images von Google gehen noch weiter: Sie enthalten weder Shell noch Paketmanager. Ein Angreifer, dem ein Einbruch in den Container gelingt, findet dort keine Werkzeuge vor.

# Standard – viele unnötige Pakete
FROM node:18

# Besser – schlanker, weniger Angriffsfläche
FROM node:18-alpine

# Optimal – keine Shell, kein Paketmanager
FROM gcr.io/distroless/nodejs18-debian12

3. Secrets nicht im Image

# FALSCH: Secret landet dauerhaft im Image-Layer
ENV DB_PASSWORD=meinPasswort123

# RICHTIG: Secret wird zur Laufzeit injiziert
# docker run -e DB_PASSWORD=$DB_PASSWORD myapp:latest
# Oder via Kubernetes External Secrets / Azure Key Vault

Für Kubernetes-Umgebungen mit Azure-Anbindung empfiehlt sich der Azure Key Vault Provider for Secrets Store CSI Driver. Er synchronisiert Secrets aus dem Key Vault direkt als Kubernetes-Secrets oder Volume-Mounts – ohne sie dauerhaft in etcd zu speichern.

4. SecurityContext in Kubernetes definieren

apiVersion: v1
kind: Pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: myapp
    image: myapp:latest
    securityContext:
      readOnlyRootFilesystem: true
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

Diese Konfiguration verhindert Privilege Escalation, schützt das Dateisystem vor Manipulation und entfernt alle Linux-Capabilities, die für die Applikation nicht notwendig sind.

5. Resource-Limits setzen

resources:
  limits:
    memory: "256Mi"
    cpu: "500m"
  requests:
    memory: "128Mi"
    cpu: "250m"

Ohne Limits kann ein einzelner kompromittierter Container alle Ressourcen eines Nodes aufbrauchen. Das ist ein trivialer DoS-Angriff von innen – und in vielen KMU-Deployments leider der Normalzustand.

Netzwerksegmentierung mit Network Policies

Ohne Network Policies kommunizieren alle Pods im Cluster uneingeschränkt miteinander – auch Pods aus unterschiedlichen Applikationen und Umgebungen. Eine Default-Deny-Policy ist der sicherste Ausgangspunkt:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Nach dieser Regel werden nur noch explizit erlaubte Verbindungen durchgelassen. Das folgt dem Prinzip der minimalen Rechtevergabe und entspricht den Anforderungen aus NIS-2 im Bereich Netzwerksegmentierung.

NIS-2 und DSGVO: Rechtliche Einordnung

Die NIS-2-Richtlinie, seit Oktober 2024 in deutsches Recht umgesetzt, verpflichtet betroffene Unternehmen zu technischen und organisatorischen Maßnahmen. Container-Umgebungen fallen darunter – insbesondere wenn sie produktionskritische Anwendungen oder personenbezogene Daten verarbeiten.

Konkret relevant:

• Art. 21 NIS-2 – Sicherheit der Lieferkette: Drittanbieter-Images und Open-Source-Komponenten müssen auf Schwachstellen geprüft werden. Ein ungepatchtes Base-Image ist ein dokumentiertes Lieferkettenrisiko.
• Schwachstellenmanagement: Regelmäßige Scans und dokumentiertes Patching von Container-Images müssen nachweisbar sein.
• Zugangskontrolle: RBAC in Kubernetes muss revisionssicher konfiguriert, dokumentiert und regelmäßig überprüft werden.

Nach DSGVO Art. 32 müssen technische Maßnahmen dem Stand der Technik entsprechen. Image-Scanning ist heute Stand der Technik. Wer es nicht betreibt, hat im Schadensfall ein Problem mit dem Nachweis angemessener Schutzmaßnahmen – und das Risiko, dass Aufsichtsbehörden das als fahrlässig einstufen.

Laufzeit-Monitoring mit Wazuh

Image-Scans prüfen den Zustand vor dem Deployment. Was im laufenden Betrieb im Container passiert, erfordert Runtime-Monitoring. Wazuh lässt sich direkt in Docker- und Kubernetes-Umgebungen integrieren:

# Wazuh-Agent als DaemonSet in Kubernetes
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: wazuh-agent
  namespace: wazuh
spec:
  selector:
    matchLabels:
      app: wazuh-agent
  template:
    metadata:
      labels:
        app: wazuh-agent
    spec:
      containers:
      - name: wazuh-agent
        image: wazuh/wazuh-agent:4.7.0
        securityContext:
          allowPrivilegeEscalation: false
        volumeMounts:
        - name: docker-sock
          mountPath: /var/run/docker.sock
          readOnly: true
      volumes:
      - name: docker-sock
        hostPath:
          path: /var/run/docker.sock

Wazuh erkennt im laufenden Betrieb:

• Neue Container, die ohne definierten Prozess gestartet werden
• Privilegierte Container (--privileged) als sofortiger Alert
• Änderungen an kritischen Dateien innerhalb von Containern (File Integrity Monitoring)
• Verdächtige Prozesse innerhalb von Containern – Reverse Shells, Crypto-Miner, Port-Scanner
• Ungewöhnliche Netzwerkverbindungen aus Containern heraus

In Kombination mit dem Wazuh-Ruleset für Docker-Aktivitäten werden diese Ereignisse als Alerts im SIEM sichtbar – in Echtzeit, nicht erst nach einem Incident.

Praxis-Checkliste: Sofortmaßnahmen für KMU

Wer heute ohne strukturierte Container-Security arbeitet, sollte mit diesen Schritten beginnen:

1. Trivy in CI/CD integrieren – kein Deployment ohne Image-Scan; Exit-Code 1 bei CRITICAL blockiert den Build
2. Private Registry nutzen – Azure Container Registry oder GitHub Container Registry statt direkter Docker-Hub-Pulls
3. Non-Root-Container – in allen eigenen Dockerfiles umsetzen, USER-Anweisung ist Pflicht
4. Kubernetes SecurityContext – readOnlyRootFilesystem, allowPrivilegeEscalation: false, Capabilities droppen
5. Default-Deny Network Policy – als Ausgangspunkt, dann gezielt erlauben
6. RBAC auditieren – kubectl auth can-i --list --as=system:serviceaccount:default:default für jeden Service Account
7. Secrets extern verwalten – Azure Key Vault oder External Secrets Operator statt Plaintext in Manifesten
8. Regelmäßige Rescans – Images nicht nur beim Build, sondern auch im Betrieb wöchentlich neu scannen

Diese acht Maßnahmen decken die häufigsten Angriffsvektoren ab und lassen sich ohne dediziertes Security-Team umsetzen.

Fazit

Container-Security ist keine Frage der Unternehmensgröße. Wer Docker und Kubernetes produktiv einsetzt, trägt die Verantwortung für die Absicherung dieser Umgebungen – unabhängig davon, ob 15 oder 1.500 Mitarbeitende im Unternehmen arbeiten. Die Tools sind verfügbar, viele kostenlos und gut dokumentiert. Was in KMU-Umgebungen fehlt, ist die strukturierte Umsetzung und das kontinuierliche Monitoring im laufenden Betrieb.

Genau dort setzt ein Managed SIEM/SOC-Dienst an: Die Container-Infrastruktur bleibt in eigener Hand, aber Anomalien, verdächtige Laufzeitaktivitäten und kritische Alerts werden durch ein spezialisiertes Team erkannt und eskaliert – ohne dass dafür intern Kapazitäten vorgehalten werden müssen. Vyrex Security betreibt dieses Modell auf Basis von Wazuh, angepasst an KMU-Anforderungen, NIS-2-konform und ohne Abhängigkeit von proprietären Plattformen. Wer wissen möchte, wie der eigene Container-Stack aktuell dasteht, kann mit einem kostenlosen Erstgespräch beginnen.