Best Practices für die Containersicherheit in Produktionsumgebungen
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Sind Ihre Behälter sicher genug für die Produktion?Container bieten eine hervorragende Isolierung zwischen Anwendungen, aber Fehlkonfigurationen, anfällige Images und unsichere Laufzeiteinstellungen können Container von einem Sicherheitsvorteil in ein Risiko verwandeln. In diesem Leitfaden werden die Sicherheitspraktiken behandelt, die für Produktionscontainerumgebungen erforderlich sind.
Wichtige Erkenntnisse
- Beginnen Sie mit minimalen Bildern:Distroless- und Alpine-Images reduzieren die Angriffsfläche um 90 % im Vergleich zu vollständigen Betriebssystem-Images.
- Scannen Sie in jeder Phase:Erstellen, pushen, bereitstellen und kontinuierlich in der Registrierung. Schwachstellen werden nach der Bereitstellung entdeckt.
- Niemals als Root ausführen:Root-Container können auf den Host entkommen. Nicht-Root-Container bleiben auch dann erhalten, wenn sie kompromittiert sind.
- Schreibgeschützte Dateisysteme:Wenn der Container nicht schreiben muss, machen Sie das Dateisystem schreibgeschützt, um die Persistenz von Malware zu verhindern.
- Die Laufzeitüberwachung erfasst, was beim Scannen übersehen wird:Zero-Day-Exploits, Angriffe auf die Lieferkette und Insider-Bedrohungen erfordern eine Laufzeiterkennung.
Bildsicherheit
Verwenden Sie nur minimale Basisbilder
Jedes Paket in einem Container-Image ist eine potenzielle Angriffsfläche. Ein typisches Ubuntu-Image enthält mehr als 100 Pakete; Ein distroless-Image enthält nur die Anwendungslaufzeit. Verwenden Sie Google Distroless für Java-, Python-, Node.js- und Go-Anwendungen. Verwenden Sie Alpine (5 MB), wenn Sie eine Shell zum Debuggen benötigen. Verwenden Sie niemals vollständige Betriebssystem-Images (Ubuntu, Debian, CentOS) in der Produktion – sie enthalten Hunderte unnötiger Pakete mit bekannten Schwachstellen.
Mehrstufige Builds
Verwenden Sie mehrstufige Docker-Dateien, um Build-Abhängigkeiten von Laufzeit-Images zu trennen. Die Build-Phase umfasst Compiler, Paketmanager und Entwicklungstools. Die letzte Stufe enthält nur die kompilierte Anwendung und minimale Laufzeitabhängigkeiten. Dadurch wird verhindert, dass Build-Tools (die häufig CVEs mit hohem Schweregrad aufweisen) in Produktionsbildern angezeigt werden.
Bildscan-Pipeline
- Bauzeit:Scannen Sie die CI-Pipeline, bevor Sie sie in die Registrierung übertragen. Blockieren Sie Builds mit kritischen Schwachstellen.
- Registrierung:Durch kontinuierliches Scannen in ECR, ACR oder Harbor werden neu entdeckte CVEs in vorhandenen Bildern erfasst.
- Eintritt:Kubernetes-Zulassungscontroller überprüfen die Ergebnisse des Bildscans, bevor sie die Bereitstellung zulassen.
- Laufzeit:Überwachen Sie auf anomales Containerverhalten, das auf die Ausnutzung ungepatchter Schwachstellen hinweisen könnte.
Laufzeitsicherheit
Behälterhärten
| Einstellung | Empfohlener Wert | Warum |
|---|---|---|
| runAsNonRoot | wahr | Verhindert Container-Escape durch Root-Rechte |
| readOnlyRootFilesystem | wahr | Verhindert, dass Malware in das Dateisystem schreibt |
| AllowPrivilegeEscalation | falsch | Verhindert, dass Prozesse zusätzliche Berechtigungen erhalten |
| Fähigkeiten | drop: ["ALL"] | Entfernt alle Linux-Funktionen, fügt nur das hinzu, was benötigt wird |
| seccompProfile | RuntimeDefault | Beschränkt die für den Container |
| verfügbaren Systemaufrufe resources.limits | CPU und Speicher einstellen | Verhindert Ressourcenmissbrauch (Krypto-Mining, DoS) |
Laufzeitüberwachung mit Falco
Falco überwacht das Containerverhalten im Hinblick auf Sicherheitsregeln und warnt bei Verstößen. Standardregeln erkennen: in einem Container erzeugte Shell, Zugriff auf vertrauliche Dateien (/etc/shadow, /etc/passwd), unerwartete Netzwerkverbindungen, Versuche zur Rechteausweitung, Paketmanagerausführung in Produktionscontainern und Krypto-Mining-Prozesse. Für Ihr spezifisches Anwendungsverhalten können benutzerdefinierte Regeln hinzugefügt werden.
Brauchen Sie Unterstützung bei Best Practices für die Containersicherheit in Produktionsumgebungen?
Unsere Cloud-Architekten unterstützen Sie bei Best Practices für die Containersicherheit in Produktionsumgebungen — von der Strategie bis zur Umsetzung. Buchen Sie ein kostenloses 30-Minuten-Beratungsgespräch ohne Verpflichtung.
Lieferkettensicherheit
Bildsignierung und -verifizierung
Signieren Sie Containerbilder zum Zeitpunkt der Erstellung mit cosign (Sigstore) oder Docker Content Trust. Überprüfen Sie die Signaturen bei der Bereitstellung über Kubernetes-Zulassungscontroller. Dadurch wird sichergestellt, dass nur von Ihrer CI/CD-Pipeline erstellte Images bereitgestellt werden können. Dadurch werden Angriffe auf die Lieferkette verhindert, bei denen Angreifer bösartige Images in Ihre Registrierung übertragen.
Software-Stückliste (SBOM)
Generieren Sie SBOMs für jedes Container-Image mit Syft oder Trivy. Eine SBOM listet alle Komponenten (Betriebssystempakete, Bibliotheken, Abhängigkeiten) im Image auf. Wenn eine neue Schwachstelle aufgedeckt wird, können Sie sofort erkennen, welche Bilder betroffen sind, ohne alles erneut scannen zu müssen. SBOMs werden zunehmend von Vorschriften und Unternehmenskunden gefordert.
Wie Opsio Container sichert
- Bildpipeline:Wir implementieren das Scannen, Signieren und Durchsetzen von Richtlinien im gesamten Lebenszyklus Ihres Container-Images.
- Laufzeitsicherheit:Wir implementieren und verwalten Falco/Sysdig für eine kontinuierliche Container-Laufzeitüberwachung.
- Kubernetes Härten:Wir härten Clusterkonfigurationen gemäß CIS-Benchmarks mit fortlaufender Compliance-Überwachung.
- Reaktion auf den Vorfall:Unser SOC-Team reagiert auf Container-Sicherheitsvorfälle mit Eindämmungs- und forensischen Fähigkeiten.
Häufig gestellte Fragen
Sind Container sicherer als VMs?
Container bieten Isolierung auf Prozessebene durch Linux-Namespaces und Kontrollgruppen, während VMs durch Hypervisoren Isolierung auf Hardwareebene bieten. VMs haben stärkere Isolationsgrenzen. Container bieten eine schnellere Bereitstellung und eine kleinere Angriffsfläche (bei Verwendung minimaler Images). In der Praxis sind ordnungsgemäß konfigurierte Container mit Laufzeitsicherheitsüberwachung für die meisten Produktions-Workloads sicher genug. Hochsensible Workloads können von der Isolierung auf VM-Ebene oder dem Container-Sandboxing (gVisor, Kata Containers) profitieren.
Was ist das größte Sicherheitsrisiko für Container?
Ausführen von Containern als Root mit uneingeschränkten Funktionen. Ein Root-Container mit allen Funktionen kann auf das Hostsystem entweichen und auf andere Container, Hostressourcen und möglicherweise auf den Kubernetes API-Server zugreifen. Die Lösung ist einfach: Setzen Sie runAsNonRoot: true, löschen Sie alle Funktionen und verwenden Sie schreibgeschützte Dateisysteme. Diese drei Einstellungen eliminieren den Großteil des Containersicherheitsrisikos.
Wie gehe ich mit Geheimnissen in Containern um?
Backen Sie niemals Geheimnisse in Container-Images ein oder übergeben Sie sie als Umgebungsvariablen (sichtbar in Prozesslisten und Protokollen). Verwenden Sie externe Geheimnisverwaltung: HashiCorp Vault mit Sidecar-Injection, AWS Secrets Manager mit ECS/EKS-Integration oder Azure Key Vault mit CSI-Treiber. Geheimnisse sollten zur Laufzeit eingefügt und nur im Speicher gespeichert werden, niemals auf der Festplatte.
Über den Autor
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.