Container Security – Docker und Kubernetes sicher betreiben

Container Security umfasst alle Maßnahmen zum Schutz von Container-Umgebungen — von der Erstellung sicherer Docker-Images über die Härtung von Kubernetes-Clustern bis zum Runtime-Schutz in der Produktion. Container haben die Softwareentwicklung verändert grundlegend, bringen aber eigene Sicherheitsherausforderungen mit sich.

Die DATUREX GmbH unterstützt Entwicklungsteams bei der Absicherung ihrer Container-Infrastruktur — von DevSecOps-Pipeline-Integration bis zum laufenden Monitoring.

Warum Container Security?

• Vergrößerte Angriffsfläche — Container-Orchestrierung (Kubernetes), Container-Registry, Host-OS, Netzwerk zwischen Containern — jede Schicht ist ein potenzielles Angriffsziel
• Schwachstellen in Images — Base-Images enthalten oft hunderte bekannte Schwachstellen (veraltete Pakete, Libraries)
• Fehlkonfigurationen — Container als Root, unbegrenzte Ressourcen, offene Ports, Secrets in Umgebungsvariablen
• Supply Chain Risiken — Manipulierte Images in öffentlichen Registries (Supply Chain Security)
• Ephemere Natur — Container werden ständig erstellt und zerstört — traditionelle Sicherheitstools greifen nicht

Container Security in der Pipeline

1. Image-Erstellung (Build-Phase)

• Minimale Base-Images — Alpine, Distroless oder Scratch statt vollwertiger OS-Images
• Multi-Stage Builds — Build-Abhängigkeiten nicht ins finale Image übernehmen
• Keine Root-User — Container als Non-Root-User ausführen (USER-Directive im Dockerfile)
• Keine Secrets im Image — API-Keys, Passwörter NIE ins Dockerfile oder in die Image-Layer
• Dockerfile Linting — Hadolint prüft Dockerfiles auf Best Practices

2. Image-Scanning (Scan-Phase)

• Trivy — Open-Source-Scanner für Container-Images, Dateisysteme und IaC. Schnell, umfangreich, CI/CD-ready
• Grype — Open-Source Vulnerability Scanner von Anchore. Schnelles Scanning, SBOM-Unterstützung
• Snyk Container — Kommerzieller Scanner mit Entwickler-freundlicher Integration und Fix-Empfehlungen
• Docker Scout — Nativ in Docker Desktop integriert, SBOM-basierte Analyse

3. Registry-Sicherheit (Store-Phase)

• Private Registry — Harbor, GitLab Registry oder Cloud-native (ECR, ACR, GCR)
• Image Signing — Cosign/Sigstore für kryptografische Image-Signaturen
• Admission Control — Nur signierte und gescannte Images dürfen deployt werden (Kyverno, OPA Gatekeeper)
• Vulnerability Policies — Images mit kritischen CVEs blockieren

4. Kubernetes-Härtung (Deploy-Phase)

• Pod Security Standards — Restricted, Baseline oder Privileged (Kubernetes-nativ seit 1.25)
• Network Policies — Container-zu-Container-Kommunikation einschränken (Zero Trust im Cluster)
• RBAC — Kubernetes Role-Based Access Control korrekt konfigurieren
• Secrets Management — External Secrets Operator, HashiCorp Vault statt Kubernetes Secrets im Klartext
• Resource Limits — CPU und Memory Limits setzen (DoS-Schutz)
• CIS Benchmarks — kube-bench prüft den Cluster gegen CIS Kubernetes Benchmark

5. Runtime-Schutz (Run-Phase)

• Falco — Open-Source Runtime Security. Erkennt verdächtiges Verhalten in laufenden Containern (Shell-Zugriff, Dateiänderungen, Netzwerkverbindungen)
• Sysdig Secure — Kommerziell, basiert auf Falco. Runtime Protection + Compliance
• Read-Only Filesystems — Container-Dateisysteme im Read-Only-Modus betreiben
• Seccomp & AppArmor — Linux Security Module für feingranulare Syscall-Filterung

Container Security Best Practices

1. Image-Scanning in die CI/CD-Pipeline — Jedes Image wird vor dem Push zur Registry gescannt
2. Minimale Images — So wenig Pakete wie möglich im finalen Image
3. Non-Root — Container NIEMALS als Root ausführen
4. Immutable Containers — Keine Änderungen am laufenden Container, nur neue Deployments
5. Network Policies — Default-Deny, nur explizit erlaubte Verbindungen
6. Secrets extern verwalten — Vault, AWS Secrets Manager, External Secrets Operator
7. Images regelmäßig rebuilden — Auch wenn kein Code-Change: Base-Image-Updates einspielen
8. SBOM generieren — Software Bill of Materials für alle Container-Images (Supply Chain Security)

DATUREX GmbH — Container Security

• Container Security Assessment — Bewertung Ihrer Docker/Kubernetes-Sicherheit
• Pipeline-Integration — Trivy, Grype, Snyk in Ihre CI/CD-Pipeline einbinden
• Kubernetes-Härtung — RBAC, Network Policies, Pod Security, CIS Benchmark
• Runtime-Monitoring — Falco-basierte Anomalie-Erkennung implementieren
• Image-Registry — Harbor-Setup mit Scanning und Admission Control
• Schulung — Container Security Training für Ihre Entwickler und DevOps-Teams

Kubernetes Security

Kubernetes Security ist eine eigene Disziplin: Die Orchestrierungsplattform bringt durch ihre Komplexität zusätzliche Angriffsflächen mit sich. Die folgenden Bereiche sind kritisch für die Absicherung von Kubernetes-Clustern.

RBAC — Role-Based Access Control

Kubernetes RBAC kontrolliert, wer was im Cluster tun darf. Konfigurieren Sie feingranulare Rollen (Roles und ClusterRoles) und binden Sie sie an konkrete Benutzer oder Service Accounts. Das Prinzip der geringsten Berechtigung ist wichtig: Ein Deployment-Service-Account braucht keine Rechte zum Löschen von Namespaces. Vermeiden Sie cluster-admin-Bindungen für normale Workloads. Auditieren Sie RBAC-Konfigurationen regelmäßig mit Tools wie kubectl-who-can oder rbac-audit.

Pod Security Standards

Kubernetes bietet seit Version 1.25 native Pod Security Standards (PSS) als Nachfolger der PodSecurityPolicy. Drei Profile stehen zur Verfügung: Privileged (keine Einschränkungen), Baseline (verhindert bekannte Privilege-Escalation-Pfade) und Restricted (maximale Sicherheit, erzwingt Non-Root, Read-Only Filesystem etc.). Setzen Sie mindestens das Baseline-Profil auf allen Namespaces und Restricted für sensitive Workloads.

Network Policies

Ohne Network Policies kann jeder Pod im Cluster mit jedem anderen Pod kommunizieren — ein Albtraum für die Sicherheit. Implementieren Sie Default-Deny-Policies auf allen Namespaces und erlauben Sie nur explizit notwendige Verbindungen. Ein Frontend-Pod sollte nur den Backend-Pod erreichen, der Backend-Pod nur die Datenbank. Tools wie Calico oder Cilium bieten erweiterte Network Policy-Funktionen über den Kubernetes-Standard hinaus.

Secrets Verschlüsselung

Kubernetes Secrets sind standardmäßig nur Base64-kodiert in etcd gespeichert — das ist keine Verschlüsselung! Aktivieren Sie Encryption at Rest für etcd und nutzen Sie den External Secrets Operator oder Sealed Secrets für eine sichere Secrets-Verwaltung. HashiCorp Vault mit dem Vault Secrets Operator ist die Enterprise-Lösung für komplexe Secrets-Management-Anforderungen.

Cluster-Härtung

Härten Sie den Kubernetes-Cluster nach CIS Kubernetes Benchmark: API-Server mit TLS absichern, anonyme Authentifizierung deaktivieren, Audit-Logging aktivieren, kubelet-Autorisierung konfigurieren, etcd verschlüsseln und zugriffsbeschränken. Nutzen Sie kube-bench von Aqua Security, um Ihren Cluster automatisiert gegen den CIS Benchmark zu prüfen und Abweichungen zu identifizieren.

Container Security in CI/CD-Pipelines

Die Integration von Container Security in CI/CD-Pipelines ist der effektivste Weg, Sicherheitsprobleme frühzeitig zu erkennen und zu beheben — bevor sie in die Produktion gelangen. Das Konzept „Shift Left Security„ bedeutet: Sicherheit so früh wie möglich im Entwicklungsprozess verankern. Eine vollständig abgesicherte DevSecOps-Pipeline umfasst mehrere Schutzschichten.

Pipeline-Stufen mit Security Gates

Stufe 1 — Source Code Security: Bereits beim Commit prüfen SAST-Tools (Static Application Security Testing) wie Semgrep oder SonarQube den Quellcode auf Sicherheitslücken. Secret-Scanner (GitLeaks, TruffleHog) verhindern, dass Passwörter oder API-Keys in das Repository gelangen. Dieser erste Gate blockiert unsicheren Code, noch bevor ein Image gebaut wird.

Stufe 2 — Dockerfile und IaC Linting: Hadolint analysiert Dockerfiles automatisch auf bekannte Sicherheitsprobleme: Verwendung von latest-Tags, fehlende USER-Direktive, ADD statt COPY, nicht deklarierte Ports. Terraform-Scanning mit Checkov oder tfsec erkennt unsichere Cloud-Konfigurationen, die den Kubernetes-Cluster gefährden könnten.

Stufe 3 — Image-Build und Scanning: Nach dem Build wird das Image mit Trivy oder Grype auf bekannte CVEs gescannt. Ein Quality Gate legt fest, ab welchem Schweregrad (Critical, High) der Pipeline-Lauf abbricht. Gleichzeitig wird ein SBOM (Software Bill of Materials) generiert, der alle Abhängigkeiten dokumentiert.

Stufe 4 — Image Signing: Nur gescannte und fehlerfreie Images werden mit Cosign kryptografisch signiert und in die Registry gepusht. Der Kubernetes-Admission-Controller (Kyverno oder OPA Gatekeeper) lehnt unsignierte Images beim Deployment automatisch ab.

Stufe 5 — Deployment Validation: Vor dem Deployment in Kubernetes prüft ein Dry-Run die Kubernetes-Manifeste mit kube-linter oder Datree auf Sicherheitskonfigurationen. Fehlende Resource Limits, falsche Security Contexts oder verbotene Capabilities werden als Pipeline-Fehler behandelt.

CI/CD-Tools im Überblick

Die Container-Security-Pipeline lässt sich in alle gängigen CI/CD-Systeme integrieren. GitHub Actions bietet fertige Actions für Trivy, Snyk und Cosign. GitLab CI integriert Container Scanning als natives Feature im Ultimate-Plan. Jenkins nutzt Plugins oder direkte Shell-Aufrufe. Azure DevOps und AWS CodePipeline bieten Cloud-native Integrationen mit den jeweiligen Registries (ACR, ECR). Die DATUREX GmbH implementiert solche Pipelines für Softwareentwicklungsprojekte aller Größenordnungen — von Startups bis zum Enterprise.

Container Hardening — Die 10 wichtigsten Härtungsmaßnahmen

Container Hardening bezeichnet die systematische Absicherung von Container-Images und -Laufzeitumgebungen gegen Angriffe. Diese 10 Maßnahmen reduzieren die Angriffsfläche Ihrer Container-Infrastruktur nachhaltig:

1. Non-Root-User erzwingen — USER-Directive im Dockerfile setzen, Pod Security Standards auf Restricted konfigurieren. Kein Container läuft als UID 0.
2. Read-Only Filesystem — readOnlyRootFilesystem: true im Security Context verhindert, dass Angreifer Malware nachinstallieren oder Konfigurationen verändern.
3. Capabilities entfernen — Mit drop: ALL alle Linux-Capabilities entfernen und nur die tatsächlich benötigten explizit hinzufügen. Die meisten Anwendungen brauchen keine Capabilities.
4. Privilege Escalation blockieren — allowPrivilegeEscalation: false verhindert, dass Prozesse innerhalb des Containers erweiterte Rechte erlangen.
5. Seccomp-Profile aktivieren — Das RuntimeDefault-Seccomp-Profil blockiert über 300 gefährliche Systemaufrufe. Für Hochsicherheitsumgebungen: Custom-Profile mit nur den tatsächlich benötigten Syscalls.
6. Resource Limits setzen — CPU- und Memory-Limits schützen vor DoS-Angriffen durch ressourcenhungrige Container. Requests und Limits sollten für jeden Container explizit definiert sein.
7. Netzwerk isolieren — Default-Deny Network Policies auf Namespace-Ebene, explizite Freigaben nur wo nötig. Service Meshes mit mTLS für verschlüsselte Pod-to-Pod-Kommunikation.
8. Immutable Images — Images nach dem Build niemals mehr verändern. Für Updates wird ein neues Image gebaut und deployt — nie in laufende Container hineinschreiben.
9. Regelmäßige Rebuilds — Auch ohne Code-Änderungen: Base-Images wöchentlich rebuilden, um aktuelle Sicherheits-Patches einzuspielen. Automatisierte Rebuild-Pipelines via Dependency-Tracking.
10. Audit-Logging aktivieren — Kubernetes Audit-Logs und Falco-Runtime-Logs in ein zentrales SIEM leiten. Verdächtige Aktivitäten wie Shell-Zugriffe oder ungewöhnliche API-Calls sofort erkennen.

Die Implementierung dieser Maßnahmen kann für App-Entwicklungsprojekte von Grund auf integriert oder nachträglich in bestehende Container-Umgebungen eingeführt werden. Die DATUREX GmbH begleitet beide Szenarien — vom Greenfield-Projekt bis zur Security-Härtung bestehender Produktionsumgebungen.

Container Security und Compliance

Container-Umgebungen unterliegen denselben regulatorischen Anforderungen wie traditionelle IT-Infrastruktur. Für Unternehmen in regulierten Branchen (Finanzsektor, Gesundheitswesen, kritische Infrastruktur) ist Container Security Compliance kein optionales Extra, sondern Pflicht. Relevante Standards umfassen ISO 27001, SOC 2, PCI DSS (für Zahlungsdaten), HIPAA (Gesundheitsdaten) und BSI IT-Grundschutz. Tools wie Sysdig Secure, Aqua Security und Prisma Cloud bieten vorgefertigte Compliance-Checks gegen diese Standards. Die DATUREX GmbH unterstützt bei der Umsetzung regulatorischer Anforderungen in Container-Umgebungen — von der Gap-Analyse über die Implementierung bis zum laufenden Compliance-Monitoring.

Zero Trust in Container-Umgebungen

Das Zero-Trust-Prinzip — „Never trust, always verify„ — ist besonders in Container-Umgebungen wichtig, wo Workloads dynamisch erstellt und zerstört werden. Jede Kommunikation zwischen Containern muss authentifiziert und autorisiert sein, unabhängig vom Netzwerkstandort. Service Meshes wie Istio und Linkerd implementieren mTLS (mutual TLS) für automatische Verschlüsselung und Authentifizierung des gesamten Service-to-Service-Traffics. Kombiniert mit feingranularen Network Policies und RBAC entsteht eine Zero-Trust-Architektur, die auch bei einem kompromittierten Container den Schaden begrenzt.

FAQ — Häufig gestellte Fragen zu Container Security

Was ist der Unterschied zwischen Docker Security und Kubernetes Security?

Docker Security fokussiert auf einzelne Container: sichere Images bauen, Schwachstellen scannen, Container-Runtime absichern. Kubernetes Security adressiert die Orchestrierungsebene: Cluster-Zugriffskontrolle (RBAC), Pod-Sicherheitsrichtlinien, Netzwerk-Segmentation zwischen Pods und Secrets-Management. Beide Ebenen müssen gemeinsam betrachtet werden — ein sicheres Docker-Image in einem unsicheren Kubernetes-Cluster bleibt verwundbar.ent. Beide Ebenen müssen gemeinsam betrachtet werden — ein sicheres Docker-Image in einem unsicheren Kubernetes-Cluster bleibt verwundbar.

Wie scanne ich Docker-Images auf Schwachstellen?

Am einfachsten mit Trivy: trivy image mein-image:latest scannt ein lokales Image in Sekunden. Für CI/CD-Integration: Trivy als Pipeline-Step einbinden, der bei kritischen CVEs den Build abbricht. Docker Desktop integriert Docker Scout nativ. Für vollständigeres Scanning empfehlen sich Snyk Container oder Aqua Security mit Anbindung an Schwachstellen-Datenbanken und Fix-Empfehlungen.

Warum sollte man Container nicht als Root ausführen?

Wenn ein Container als Root läuft und ein Angreifer es schafft, aus dem Container auszubrechen (Container Escape), hat er Root-Rechte auf dem Host-System — und damit volle Kontrolle über alle Container und den Server selbst. Non-Root-Container begrenzen den Schaden bei einem erfolgreichen Angriff erheblich. Zusätzlich sollten Seccomp-Profile und AppArmor eingesetzt werden, um die verfügbaren Systemaufrufe einzuschränken.heblich. Zusätzlich sollten Seccomp-Profile und AppArmor eingesetzt werden, um die verfügbaren Systemaufrufe einzuschränken.

Was ist ein SBOM und warum ist es wichtig?

Ein Software Bill of Materials (SBOM) ist eine vollständige Liste aller Softwarekomponenten in einem Container-Image — vergleichbar mit einer Zutatenliste auf Lebensmitteln. SBOMs ermöglichen es, bei Bekanntwerden einer neuen Schwachstelle (wie Log4Shell) sofort zu identifizieren, welche Container betroffen sind. Tools wie Syft generieren SBOMs automatisch. Regulatorische Anforderungen (US Executive Order on Cybersecurity, EU Cyber Resilience Act) machen SBOMs zunehmend zur Pflicht.etroffen sind. Tools wie Syft generieren SBOMs automatisch. Regulatorische Anforderungen (US Executive Order on Cybersecurity, EU Cyber Resilience Act) machen SBOMs zunehmend zur Pflicht.

Was kostet ein Container Security Assessment?

Der Aufwand für ein Container Security Assessment hängt von der Größe und Komplexität der Container-Infrastruktur ab. Ein fokussiertes Assessment einer mittelgroßen Kubernetes-Umgebung (5–20 Workloads) dauert typischerweise 3–5 Tage und umfasst: Analyse der Dockerfile-Qualität, Image-Scanning-Ergebnisse, RBAC-Audit, Network-Policy-Review und Cluster-Härtung nach CIS Benchmark. Das Ergebnis ist ein priorisierter Maßnahmenplan. Sprechen Sie uns für ein unverbindliches Erstgespräch an.isse, RBAC-Audit, Network-Policy-Review und Cluster-Härtung nach CIS Benchmark. Das Ergebnis ist ein priorisierter Maßnahmenplan. Sprechen Sie uns für ein unverbindliches Erstgespräch an.