Container- und Docker-Image-Sicherheit von Anfang bis Ende

Container versprechen eine saubere, reproduzierbare Softwareeinheit, doch dieses Versprechen hält nur, wenn Image, Build-Pipeline, Registry und Laufzeit gemeinsam abgesichert sind. Eine in einem Basis-Image eingeführte Schwachstelle, ein in eine Schicht eingebranntes Secret oder ein kompromittierter Build-Schritt kann unverändert in jede Umgebung wandern, die das Artefakt zieht. Dieser Artikel durchläuft den Container-Lebenszyklus von Anfang bis Ende aus Verteidigersicht, gerahmt als verstehen, um zu verteidigen. Wir betrachten, wo in jeder Phase Risiko eintritt, welche Telemetrie Missbrauch erkennen lässt und welche Kontrollen ein Container-Image vertrauenswürdig machen — vom Laptop des Entwicklers bis zum Produktionsknoten.

Die Container-Lieferkette als Angriffsfläche

Es hilft, ein Container-Image nicht als Datei zu denken, sondern als Beweiskette. Quellcode wird zum Build, der Build zieht Abhängigkeiten und ein Basis-Image, das Ergebnis wird in eine Registry geschoben, und ein Scheduler führt es schließlich irgendwo aus. Jedes Glied ist eine Stelle, an der ein Angreifer oder ein Versehen etwas Ungewolltes einschleusen kann. Das Verteidigungsziel ist Herkunft: An jedem Punkt sollten Sie beantworten können, woher ein Image stammt, was hineinfloss, wer es baute und ob es seither verändert wurde. Fehlt die Herkunft, kann eine einzige vergiftete Schicht sich still über Ihre gesamte Flotte verbreiten.

Deshalb steht Lieferketten-Denken heute im Zentrum der Container-Sicherheit. Es genügt nicht, das Endbild zu scannen; Sie müssen den Prozess absichern, der es erzeugt, und beweisen können, dass das in Produktion Laufende genau das ist, was Ihre Pipeline gebaut hat. Denken Sie daran, dass ein Angreifer nicht unbedingt Ihre Anwendung angreifen muss: Es reicht, wenn er ein einziges Glied früher in der Kette manipuliert, etwa ein Basis-Image oder eine Abhängigkeit, und die Manipulation reist dann automatisch in jede Umgebung, die das Artefakt verwendet.

Basis-Images wählen und pflegen

Der Großteil der Angriffsfläche eines Images stammt aus dem Geerbten, nicht aus dem Selbstgeschriebenen. Ein Basis-Image voller Shells, Paketmanager und Systemwerkzeuge gibt einem Eindringling im Moment der Landung einen Werkzeugkasten. Bevorzugen Sie minimale oder distroless Basen, die nur Ihre Anwendung und deren Laufzeitabhängigkeiten enthalten, und heften Sie sie an einen unveränderlichen Digest statt an ein veränderliches Tag wie latest, damit ein Rebuild nicht still ein anderes, möglicherweise manipuliertes Image zieht. Bauen Sie regelmäßig neu, um vorgelagerte Sicherheitskorrekturen aufzunehmen; ein angehefteter Digest, der nie aktualisiert, ist gegen Überraschung sicher, sammelt aber langsam bekannte Schwachstellen an.

Verfolgen Sie die Herkunft Ihrer Basis-Images. Bevorzugen Sie offizielle oder verifizierte Herausgeber und behandeln Sie eine ungepflegte Quelle als Belastung. Je weniger Pakete ein Image enthält, desto kleiner die zu patchende Fläche und desto leiser Ihr Schwachstellen-Scanner, was wiederum echte Funde leichter sichtbar macht.

Images sicher bauen

Der Build ist der Ort, an dem Secrets am häufigsten leaken. Ein als Build-Argument übergebenes oder in einer Phase kopiertes und in einer späteren gelöschtes Anmeldeinformationsdatum lebt weiterhin in der Image-Historie und ist von jedem wiederherstellbar, der das Image zieht. Nutzen Sie Build-Zeit-Secret-Mounts, die nie in eine Schicht persistieren, und halten Sie Secrets ganz aus dem Dockerfile heraus. Mehrstufige Builds erlauben, in einer fetten Builder-Phase zu kompilieren oder zu installieren und nur das fertige Artefakt in eine schlanke Endphase zu kopieren, wobei Compiler, Paket-Caches und Zwischen-Anmeldedaten zurückbleiben.

Führen Sie den Container als Nicht-root-Benutzer aus, indem Sie im Image einen eigenen Benutzer deklarieren, damit selbst eine Laufzeit, die den Benutzer nicht überschreibt, nicht als root läuft. Wählen Sie ein schreibgeschützt-freundliches Dateisystemlayout, vermeiden Sie ADD mit entfernten URLs und bevorzugen Sie COPY mit expliziten Quellen. Erzeugen Sie beim Build eine Software-Stückliste, damit Sie ein Inventar jeder Komponente haben, das am Tag der Offenlegung einer neuen Schwachstelle unschätzbar wird, wenn Sie sofort wissen müssen, ob Sie betroffen sind.

Herkunft signieren und verifizieren

Eine Signatur macht aus Herkunft von einer Behauptung etwas Durchsetzbares. Signieren Sie Images am Ende des Builds mit einem Werkzeug wie cosign von Sigstore und zeichnen Sie Attestierungen auf, die beschreiben, wie das Image gebaut wurde und was hineinfloss. Zur Bereitstellungszeit prüft ein Admission-Controller oder eine Policy-Engine diese Signatur und weigert sich, etwas Unsigniertes oder mit einem unerwarteten Schlüssel Signiertes auszuführen. Das schließt die Lücke zwischen Registry und Laufzeit: Selbst wenn ein Angreifer ein bösartiges Image in Ihre Registry schiebt, kann es ohne gültige Signatur aus Ihrer Pipeline nicht laufen.

Schlüsselloses Signieren, das an Ihre CI-Identität gebunden ist, nimmt die Last langlebiger Signierschlüssel und bindet jede Signatur an einen überprüfbaren Workflow. Die entscheidende Verteidigungseigenschaft ist, dass Vertrauen aus Ihrem Build-System fließt und nicht aus der bloßen Tatsache, dass ein Image in Ihrer Registry liegt.

Scannen und Torkontrolle

Schwachstellen-Scanning gehört an mehrere Punkte: in den Pull Request, damit Entwickler Probleme früh sehen, in die Pipeline als Tor, das den Build scheitern lassen kann, und fortlaufend gegen bereits in der Registry liegende Images, weil neue Schwachstellen gegen unveränderte Images offengelegt werden. Konfigurieren Sie das Tor mit einer Richtlinie, die zu Ihrem Risiko passt — etwa auf behebbare kritische und hohe Befunde blockieren, den Rest verfolgen — und geben Sie Teams einen klaren Ausnahmeweg mit Ablauf, damit Tore unter Fristdruck nicht einfach deaktiviert werden. Scannen Sie auch auf eingebettete Secrets und Fehlkonfigurationen, nicht nur auf bekannte Paketschwachstellen.

Bedenken Sie, dass ein Scanner meldet, was er heute weiß. Paaren Sie ihn mit der Software-Stückliste, damit Sie beim Auftauchen einer brandneuen Schwachstelle Ihr Inventar abfragen können, statt die Welt neu zu scannen. Die Kombination aus Tor und Inventar lässt Sie in Minuten statt Tagen reagieren.

Laufzeitschutz und Registry-Hygiene

Sobald ein Container läuft, verschieben sich die Kontrollen auf sein Einschränken und Beobachten. Verwerfen Sie Linux-Capabilities, wenden Sie ein Seccomp-Profil an, laufen Sie mit schreibgeschütztem Wurzeldateisystem und gewähren Sie niemals das privileged-Flag oder hängen den Docker-Socket des Hosts in einen Container ein, denn beides übergibt faktisch den Knoten. Auf Registry-Seite verlangen Sie Authentifizierung, begrenzen Pull- und Push-Rechte eng, aktivieren unveränderliche Tags, damit ein veröffentlichtes Image nicht unter Konsumenten ausgetauscht werden kann, und entfernen nicht vertrauenswürdige oder veraltete Images. Eine Registry, in die jeder pushen kann, ist ein Vertriebskanal für alles, was ein Angreifer laufen lassen will.

Isolieren Sie Build-Runner von Produktions-Anmeldedaten. Ein kompromittierter CI-Runner mit breitem Zugriff ist einer der schädlichsten Brückenköpfe, die ein Angreifer bekommen kann, weil er genau die Images umschreiben kann, denen Sie vertrauen. Geben Sie Runnern minimale Rechte, kurzlebige Identitäten und keinen dauerhaften Produktionszugriff. Behandeln Sie die Pipeline selbst als schützenswertes Produktionssystem: Wer die Build-Definitionen ändern darf, kann letztlich bestimmen, was in Produktion läuft, weshalb Änderungen an der Pipeline dieselbe Prüfung und Nachvollziehbarkeit verdienen wie Änderungen am Anwendungscode.

Erkennung: Signale über den Lebenszyklus

Erkennung spannt sich über die ganze Kette. In der Pipeline achten Sie auf Builds, die aus unerwarteten Quellen ziehen, auf Signatur-Prüffehler und auf plötzliche Spitzen bei Scanner-Funden. In der Registry alarmieren Sie bei Pushes aus ungewöhnlichen Identitäten, bei Pulls nie beförderter Images und bei Tag-Mutationen, wo Sie Unveränderlichkeit erwarteten. Zur Laufzeit meldet ein Verhaltenssensor wie Falco oder ein container-bewusstes EDR eine in einem Container gestartete Shell, einen Prozess, der auf einen schreibgeschützten Pfad schreibt, eine unerwartete ausgehende Verbindung oder einen Versuch, den Container-Runtime-Socket zu erreichen. Einen Registry-Push mit einem anomalen Laufzeitverhalten zu korrelieren, enthüllt oft ein vergiftetes Image, bevor es sich verbreitet.

Bewahren Sie diese Logs länger auf als die typische Verweildauer eines Angreifers und verschicken Sie sie von den erzeugenden Hosts weg. Herkunftsdaten, Signatur-Prüfergebnisse und Laufzeit-Alarme zusammen lassen Sie die Frage jedes Vorfalls beantworten: Was lief, woher kam es, und läuft es noch anderswo?

Eine praktische Checkliste

Basis: minimal oder distroless, an einen Digest geheftet, von einem verifizierten Herausgeber, regelmäßig neu gebaut. Build: Nicht-root-Benutzer, mehrstufig, Secret-Mounts statt Build-Argumente, Software-Stückliste erzeugt, kein Host-Socket. Herkunft: Images signiert, Attestierungen aufgezeichnet, Admission prüft Signaturen. Scannen: im PR, in der Pipeline als Tor, fortlaufend in der Registry, Secret- und Fehlkonfigurations-Scan inklusive, Ausnahmen befristet. Registry: authentifiziert, minimalprivilegiertes Push, unveränderliche Tags, veraltete Images entfernt. Laufzeit: verworfene Capabilities, Seccomp, schreibgeschütztes Dateisystem, kein privileged, kein Docker-Socket-Mount. Erkennung: Pipeline-, Registry- und Laufzeit-Alarme korreliert, Logs über die Verweildauer hinaus aufbewahrt.

FAQ: Macht Scannen meine Images sicher?

Scannen ist notwendig, aber nicht hinreichend. Es informiert über bekannte Schwachstellen in bekannten Komponenten, was wertvoll ist, sagt aber nichts über einen bösartigen Build-Schritt, ein nicht erkanntes geleaktes Secret, eine überprivilegierte Laufzeit oder eine morgen offengelegte brandneue Schwachstelle. Behandeln Sie Scannen als eine Schicht neben Herkunft, Signieren, minimalen Images, Laufzeit-Einschränkung und Erkennung. Sicherheit kommt aus der Kombination, nicht aus einem einzelnen Tor.

FAQ: Sind distroless oder minimale Images immer besser?

Sie verringern Angriffsfläche und Scanner-Rauschen drastisch und sind für die meisten Produktionsdienste die richtige Voreinstellung. Der Kompromiss ist Fehlersuchbarkeit, da es keine Shell und keinen Paketmanager zum Herumstochern gibt, wenn etwas bricht. Die reife Antwort ist, Produktions-Images minimal zu halten und kurzlebige Debug-Container oder ein separates reicheres Image zur Fehlersuche zu nutzen, sodass Sie in Produktion eine kleine Fläche haben, ohne die Untersuchungsfähigkeit zu verlieren.

Fazit

Container-Sicherheit ist keine einzelne Kontrolle, sondern eine Kette, die nur so stark ist wie ihr schwächstes Glied. Beginnen Sie mit einer minimalen, angehefteten, verifizierten Basis; bauen Sie ohne Secret-Leck und als Nicht-root-Benutzer; signieren und attestieren Sie, damit Herkunft durchsetzbar ist; scannen und torkontrollieren Sie in jeder Phase; sperren Sie Registry und Laufzeit ab; und instrumentieren Sie den ganzen Lebenszyklus, damit Missbrauch sichtbar wird. Wenn Herkunft ungebrochen von der Quelle zum laufenden Container fließt, hat eine vergiftete Schicht kein Versteck, und die Reproduzierbarkeit, die Container attraktiv macht, macht sie zugleich verteidigbar.