Wie sichert man einen Container?

Sie sichern einen Container, indem Sie mehrschichtige Kontrollmechanismen auf die fünf Komponenten des Container-Stacks anwenden: das Image, die Registry, den Orchestrator, den laufenden Container und das Host-Betriebssystem. Die NIST Special Publication 800-190, der „Application Container Security Guide“, definiert dieses mehrschichtige Modell und seine Gegenmaßnahmen.

Um einen Container abzusichern, sollten Images vor der Bereitstellung auf Schwachstellen geprüft, ausschließlich aus vertrauenswürdigen privaten Registries bezogen, signiert (um ihre Herkunft verifizieren zu können), Container mit minimalen Berechtigungen und ohne Root-Rechte ausgeführt, das Orchestrator- und das Host-Betriebssystem gehärtet, sensible Daten aus den Images ferngehalten und das Laufzeitverhalten kontinuierlich überwacht werden. NIST SP 800-190 definiert diese Gegenmaßnahmen.

Wichtige Erkenntnisse

• Die Containersicherheit umfasst fünf Ebenen, die in NIST SP 800-190 definiert sind: Image, Registry, Orchestrator, Container-Laufzeitumgebung und Host-Betriebssystem.
• Minimale Basis-Images, Ausführung ohne Root-Rechte und Image-Signierung eliminieren die häufigsten Angriffswege für Container vor der Bereitstellung.
• Kubernetes hat die PodSecurityPolicy in Version 1.25 entfernt; Pod Security Admission erzwingt nun die Standards Privileged, Baseline und Restricted über Namespace-Labels.
• Docker begann im August 2025 mit der Abschaffung von Docker Content Trust; Sigstore Cosign und Notary Project Notation sind die aktuellen Standards für die Signierung von Container-Images.
• Jede Containerplattform basiert auf Schlüsseln, Zertifikaten und Geheimnissen. Signaturschlüssel gehören in ein HSM und Zugangsdaten in einen Geheimnismanager, niemals in das Image selbst.

Was ist ein Container?

Ein Container ist eine eigenständige Softwareeinheit, die den Anwendungscode zusammen mit seinen Abhängigkeiten verpackt, sodass die Anwendung in verschiedenen Computerumgebungen konsistent ausgeführt werden kann.

Container sind eine Form der Betriebssystemvirtualisierung. Ein Container enthält die ausführbaren Dateien, Binärdateien, Bibliotheken und Konfigurationsdateien, die eine Anwendung benötigt, jedoch kein vollständiges Betriebssystemabbild. Dadurch bleiben Container schlank und portabel. Ein einzelner Container kann alles ausführen, von einem kleinen Microservice bis hin zu einer größeren Anwendung.

Container werden aus Container-Images erstellt. Ein Image besteht aus mehreren Dateiebenen, wobei das Basis-Image die unterste und die Anwendungsebenen darüber liegen. Da jedes abgeleitete Image die Basisebene erbt, ist diese die wichtigste Ebene für die Sicherheit.

Was ist Container-Management?

Container-Management ist die Automatisierung der Erstellung, Bereitstellung und Skalierung von Containern in einer Umgebung.

Container-Management-Plattformen ermöglichen es Teams, Container in großem Umfang hinzuzufügen, zu ersetzen und zu organisieren. Konkret bedeutet dies, die von Teams heruntergeladenen und erstellten Images zu analysieren und zu kontrollieren, sie in privaten Registries zu hosten, rollenbasierte Zugriffsrechte anzuwenden, Richtlinien zu automatisieren und Schwachstellen aufzudecken, bevor Images in der Produktion eingesetzt werden. Die Automatisierung reduziert menschliche Fehler, die bei manuellen Containeroperationen auftreten können.

Warum ist Containersicherheit wichtig?

Die Sicherheit von Containern ist deshalb so wichtig, weil Container mittlerweile einen großen Teil der Produktions-Workloads ausführen und ein einzelner anfälliger Container zu einem Einfallstor in die gesamte Infrastruktur werden kann.

Container bieten zwar echte Isolationsvorteile, vergrößern aber gleichzeitig die Angriffsfläche. Container auf demselben Host teilen sich den Host-Kernel, sodass ein Container-Escape alle Workloads auf diesem Rechner gefährdet. Der Großteil des Container-Datenverkehrs findet in der Ost-West-Richtung zwischen Diensten innerhalb des Clusters statt und ist für Perimeter-Tools wie Web Application Firewalls und Intrusion Prevention Systems nicht ausgelegt. Speziell entwickelte Kontrollmechanismen müssen diese Lücke schließen.

Wie sichert man einen Container? Das NIST SP 800-190 Modell

Der vom NIST im September 2017 als Special Publication 800-190 veröffentlichte Leitfaden zur Sicherheit von Anwendungscontainern gliedert die Containersicherheit in fünf Komponenten: Images, Registries, Orchestratoren, Container und das Host-Betriebssystem. Die Absicherung eines Containers erfordert die Anwendung von Kontrollmechanismen auf jeder Ebene.

Schicht	Primäre Risiken	Kernsteuerungen
Bild	Bekannte Schwachstellen, eingebettete Geheimnisse, nicht vertrauenswürdige Quellen	Scannen Sie in CI und in der Registry, verwenden Sie minimale Basis-Images, signieren Sie mit Cosign oder Notation.
Registratur	Veraltete Bilder, unsicherer Zugriff	Private Registry, starke Authentifizierung, alte Images löschen, Scannen bei Push-Benachrichtigung
Koordinationsrechner	Unbegrenzter Administratorzugriff, ungeschützter Pod-zu-Pod-Datenverkehr	RBAC-Privilegienprinzip, Pod-Sicherheitszulassung, Netzwerkrichtlinien
Container	Laufzeitangriffe, Rechteausweitung, Image-Drift	Benutzer ohne Root-Rechte, eingeschränkte Berechtigungen, Bedrohungserkennung zur Laufzeit
Host-Betriebssystem	Große Angriffsfläche, gemeinsam genutzter Kernel	Containerspezifisches Host-Betriebssystem, zeitnahes Patchen, eingeschränkter Zugriff

Drei Empfehlungen des NIST verdienen besondere Beachtung. Erstens: Container sollten auf einem speziell für Container entwickelten Host-Betriebssystem ausgeführt werden. Dieses bietet weniger Funktionen und eine geringere Angriffsfläche als ein Allzweck-Betriebssystem. Zweitens: Container sollten nach Zweck, Sensibilität und Risikoprofil auf separaten Hosts gruppiert werden, sodass die Kompromittierung einer Gruppe einem Angreifer nicht automatisch Zugriff auf die anderen ermöglicht. Drittens: Es sollten containerbasierte Tools für Schwachstellenmanagement und Laufzeitsicherheit eingesetzt werden. Herkömmliche Scanner weisen Schwächen im Bereich der Image-Ebenen und der Konfiguration auf und können fälschlicherweise einen einwandfreien Zustand melden.

Best Practices für die Sicherheit von Docker-Containern

Die wirksamsten Docker-Kontrollen sind minimal vertrauenswürdige Images, minimale Privilegien zur Laufzeit und signierte Artefakte.

1. Verwenden Sie minimale, vertrauenswürdige Basisbilder: Verwenden Sie ausschließlich vertrauenswürdige Quellen wie offizielle Docker-Images und verifizierte Herausgeber und bevorzugen Sie schlanke oder distrolose Varianten. Weniger Pakete bedeuten weniger potenzielle Sicherheitslücken.
2. Als Nicht-Root-Benutzer mit minimalen Berechtigungen ausführen: Legen Sie im Dockerfile einen Benutzer ohne Root-Rechte fest, entfernen Sie Linux-Funktionen, die die Anwendung nicht benötigt, und vermeiden Sie den privilegierten Modus.
3. Geheimnisse sollten aus den Bildern herausgehalten werden: Passwörter, Token oder Schlüssel dürfen niemals in eine Dockerfile oder eine Image-Ebene eingebettet werden. Zugangsdaten werden zur Laufzeit über einen Secrets Manager eingebunden.
4. Bilder signieren und überprüfen: Verwenden Sie Sigstore Cosign oder Notary Project Notation. Docker hat am 8. August 2025 mit der Abschaffung von Docker Content Trust begonnen, und der zugehörige Notary v1-Dienst wird am 8. Dezember 2026 eingestellt. Erstellen Sie daher keine neuen Verifizierungsmechanismen auf Basis von DCT.
5. Kontinuierlich scannen und neu erstellen statt patchen.Scanne Images in der Pipeline und in der Registry und behandle Container als kurzlebig und unveränderlich. Sobald ein Fix verfügbar ist, erstelle und stelle das Image erneut bereit.
6. Führen Sie SSH nicht innerhalb von Containern aus: Fehlerbehebung sollte über docker exec oder den Orchestrator erfolgen, anstatt in jeder Arbeitslast einen Login-Daemon mitzuliefern.

Kubernetes-Container-Sicherheit – Bewährte Verfahren

Die Sicherheit von Kubernetes beginnt mit einer unterstützten Version und der Durchsetzung von Richtlinien auf Namespace-Ebene.

• Bleiben Sie bei einer unterstützten Version: Kubernetes veröffentlicht drei kleinere Versionen pro Jahr, die jeweils etwa 14 Monate lang mit Patches versorgt werden. Die Verwendung einer nicht unterstützten Version bedeutet, dass keine Sicherheitsupdates verfügbar sind.
• Pod-Sicherheitsstandards durchsetzenDie PodSecurityPolicy wurde in Version 1.21 als veraltet markiert und in Version 1.25 entfernt. Wenden Sie den Baseline- oder Restricted-Standard über die Namespace-Labels für Pod Security Admission an und fügen Sie eine Policy-Engine wie OPA Gatekeeper oder Kyverno hinzu, wenn Sie benutzerdefinierte Regeln benötigen.
• Zugang sperren: Wenden Sie das Prinzip der rollenbasierten Zugriffskontrolle (RBAC) mit minimalen Berechtigungen auf den API-Server an und beschränken Sie die Berechtigungen. SSH Zugriff auf die Knoten. Port 22 sollte auf jedem Knoten außer über Ihr VPN oder einen Bastion-Pfad geschlossen sein.
• Namensräume und Netzwerkrichtlinien als Grenzen verwenden: Workloads sollten in Namespaces unterteilt und NetworkPolicy-Objekte angewendet werden, damit Pods nur mit den Diensten kommunizieren können, die sie benötigen.
• Geheimnisse schützen: Aktivieren Sie die Verschlüsselung ruhender Kubernetes-Secrets und bevorzugen Sie einen externen Secrets-Speicher für besonders wichtige Anmeldeinformationen.
• Prüfen und überwachen: Aktivieren Sie die Audit-Protokolle und lassen Sie sich bei Autorisierungsfehlern warnen, da diese häufig auf gestohlene Zugangsdaten hinweisen, die gegen die API verwendet werden.

AWS-Container-Sicherheit – Bewährte Verfahren

Bei AWS liegt der Fokus der Container-Sicherheit auf Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service (EKS) und dem Image-Scanning in Amazon Elastic Container Registry (ECR).

• Scannen im ECR: Aktivieren Sie den Scan bei Push-Vorgängen. Der Basisscan nutzt native AWS-Technologie, um Schwachstellen in Betriebssystempaketen zu finden. Der erweiterte Scan, eine Integration mit Amazon Inspector, ergänzt diese um Programmiersprachenpakete, führt kontinuierliche Neuscans durch, sobald neue CVEs veröffentlicht werden, und deckt seit 2025 auch grundlegende Images wie Scratch-, Distroless- und Chainguard-Images ab. Inspector ordnet Images außerdem den ECS- und EKS-Workloads zu, auf denen sie ausgeführt werden. So können Sie zuerst die tatsächlich bereitgestellten Images beheben.
• Respektiere das Modell der gemeinsamen VerantwortungAWS sichert die zugrundeliegende Infrastruktur; Sie sichern Ihre Images, Aufgaben- und Pod-Konfigurationen, IAM-Berechtigungen und den Netzwerkzugriff. Tools wie Prowler helfen bei der Überprüfung der Umgebung vor der Bereitstellung.
• Unnötige Berechtigungen entfernen: Weisen Sie Aufgaben und Pods IAM-Rollen mit Bereichsbezug zu, anstatt umfassende Berechtigungen auf Knotenebene zu vergeben. Je mehr Standardzugriff ein Container hat, desto größer ist der potenzielle Schadensradius und desto schwieriger ist die forensische Analyse nach einem Sicherheitsvorfall.
• Blicken Sie über den Tellerrand hinaus: Prüfen Sie auch die Hosts und die Steuerungsebene, scannen Sie regelmäßig und halten Sie alle Komponenten auf dem neuesten Stand.

Bewährte Sicherheitspraktiken für Microsoft Azure Container

Bei Azure liegt der Fokus der Containersicherheit auf Azure Container Registry (ACR) und Microsoft Defender for Containers.

• Verwenden Sie ein privates Register: Speichern und laden Sie Images von ACR anstatt aus öffentlichen Repositories, da öffentliche Images aus vielen Softwareebenen bestehen und jede Ebene Sicherheitslücken aufweisen kann. Beachten Sie, dass ACR Docker Content Trust zugunsten der Notary Project-Signatur mit Notation einstellt (Einstellung begann am 31. März 2025, endgültige Entfernung am 31. März 2028).
• Scannen mit Defender für Container: Microsoft Defender for Cloud, der Dienst, der bis zu seiner Umbenennung im November 2021 Azure Security Center hieß, führt agentenlose Schwachstellenanalysen von ACR-Images mithilfe von Microsoft Defender Vulnerability Management durch. Der zuvor integrierte Qualys-Containerscanner wurde im März 2024 eingestellt.
• Sichere Anmeldeinformationen: Da Container über verschiedene Regionen und Cluster verteilt sind, sollten Passwörter, Token und API-Schlüssel in Azure Key Vault gespeichert und verwaltete Identitäten für die Dienst-zu-Dienst-Authentifizierung anstelle von eingebetteten Geheimnissen verwendet werden.

Welche Rolle Kryptographie in der Containersicherheit spielt

Jede Schicht einer Containerplattform ist auf Schlüssel, Zertifikate und Geheimnisse angewiesen.

Image-Signaturen sind nur so sicher wie die dahinterliegenden privaten Schlüssel. Daher gehören Signaturschlüssel in ein Hardware-Sicherheitsmodul oder ein verwaltetes KMS, nicht auf einen Build-Server. TLS-Zertifikate schützen den Datenverkehr zwischen Registries, API-Servern und Workloads. Service Meshes gehen noch einen Schritt weiter und verwenden Mutual TLS zwischen Pods. Dies erfordert die Ausstellung und Rotation von Zertifikaten in Echtzeit durch Ihre Public-Key-Infrastruktur (PKI) . Pipeline- und Workload-Identitäten folgen demselben Prinzip wie die DevOps-Toolchain , in der sie ausgeführt werden: kurzlebige Anmeldeinformationen, zentral ausgestellt und sofort widerrufbar. Eine Container-Plattform ist nur so vertrauenswürdig wie die Schlüssel, Zertifikate und Geheimnisse, die sie betreiben.

Wie Verschlüsselungsberatung hilft

Die Securing DevOps-Lösungen von Encryption Consulting schützen die kryptografische Ebene, auf der jede Container-Pipeline basiert. CodeSign Secure zentralisiert die Signierung von Code und Artefakten hinter FIPS 140-2 Level 3-validierten HSMs und integriert sich in CI/CD-Tools wie Jenkins, GitLab und Azure DevOps. So wird jedes Image und Artefakt signiert, mit einem Zeitstempel versehen und protokolliert, ohne die Auslieferung zu verlangsamen. Unsere Beratungsteams unterstützen Sie anschließend bei der Verwaltung der Zertifikate, Schlüssel und Geheimnisse, auf denen Ihre Cluster laufen. Die Lösungen basieren auf ISO/IEC 27001:2022- und SOC 2-zertifizierten Verfahren.

Häufig gestellte Fragen

Was versteht man unter Containersicherheit in einfachen Worten?

Container-Sicherheit bezeichnet den Schutz containerisierter Anwendungen auf allen Ebenen: vom Image, aus dem der Container erstellt wird, über die Registry, in der er gespeichert ist, und den Orchestrator, der ihn plant, bis hin zum laufenden Container selbst und dem zugrunde liegenden Host-Betriebssystem. NIST SP 800-190 definiert die Risiken und Gegenmaßnahmen für jede dieser fünf Ebenen.

Wie sichert man einen Docker-Container?

Verwenden Sie ein minimales, vertrauenswürdiges Basis-Image und erstellen Sie dieses regelmäßig neu, anstatt laufende Container zu patchen. Führen Sie den Container als Benutzer ohne Root-Rechte aus, entfernen Sie unnötige Linux-Funktionen und betten Sie niemals Anmeldeinformationen in das Image ein. Scannen Sie Images in der Pipeline und der Registry und signieren Sie sie mit Sigstore Cosign oder Notation, damit nur verifizierte Images in die Produktion gelangen.

Was ist NIST SP 800-190?

Die NIST-Sonderveröffentlichung 800-190, der „Application Container Security Guide“, wurde im September 2017 vom US-amerikanischen National Institute of Standards and Technology (NIST) herausgegeben. Sie beschreibt die Sicherheitsrisiken von Containertechnologien in Bezug auf Images, Registries, Orchestratoren, Container und Host-Betriebssysteme und empfiehlt entsprechende Gegenmaßnahmen. Sie gilt weiterhin als grundlegende Referenz für Container-Sicherheitsprogramme und -Audits.

Was hat die Pod-Sicherheitsrichtlinien in Kubernetes ersetzt?

Pod Security Admission ersetzte PodSecurityPolicy, das in Kubernetes 1.21 als veraltet markiert und in Version 1.25 entfernt wurde. Pod Security Admission erzwingt die drei Pod-Sicherheitsstandards Privileged, Baseline und Restricted mithilfe von Namespace-Labels. Teams, die feinere Regeln als die integrierten Standards benötigen, verwenden in der Regel zusätzlich eine Policy-Engine wie OPA Gatekeeper oder Kyverno.

Sollen Container-Images signiert werden?

Ja. Durch die Signierung kann Ihr Cluster überprüfen, ob ein Image von einem vertrauenswürdigen Herausgeber stammt und nach der Erstellung nicht verändert wurde. Docker Content Trust, der ältere Signaturmechanismus, wird seit August 2025 nicht mehr unterstützt, und der zugehörige Notary v1-Dienst wird im Dezember 2026 eingestellt. Daher sollten neue Pipelines Sigstore Cosign oder Notary Project Notation verwenden, und die Zugriffskontrollen sollten verhindern, dass unsignierte Images in die Produktionsumgebung gelangen.

Sichern Sie Ihre Container-Pipeline

Signierte Images, geschützte Schlüssel und gehärtete Cluster gewährleisten die Vertrauenswürdigkeit einer schnellen Containerplattform. Erfahren Sie mehr über die DevOps-Sicherheit , sehen Sie CodeSign Secure in Aktion oder sprechen Sie mit einem Berater von Encryption Consulting.