Wie bösartige Docker-Images in vertrauenswürdige Pipelines Unbemerkt
Ein Docker-Register ist das Herzstück jedes containerisierten Workflows. Es speichert, verteilt und versioniert Images. Wenn es jedoch ungeschützt oder nur unzureichend kontrolliert wird, können Angreifer schädliche Docker-Images direkt in pipelines.
Wie es passiert:
- Open-Pull-Richtlinien: Ein pipeline zieht myorg/base: neueste ohne Überprüfung der Quelle oder Integrität
- Kompromittierte Konten: Angreifer verschaffen sich Zugriff auf ein Container-Registry und ersetzen vertrauenswürdige Images
- Tippfehler: Entwickler ziehen fälschlicherweise myorg-base statt myorg/base
Beispiel in einem GitLab CI-Job:
Dabei steht: Knoten: neuste kann sich über Nacht ändern. Wenn es einem Angreifer gelingt, eine vergiftet neuesten Image, es wird automatisch gezogen. Sichere Version:
Durch das Sperren von Images auf eine bestimmte Version wird ein unbemerkter Drift verhindert. Ein schädliches Docker-Image kann nur eindringen, wenn Sie der Version „latest“ blind vertrauen.
Warum nicht alle Docker-Registries standardmäßig sicher sind
Nicht jedes Docker-Register erzwingt strenge Standardwerte. Entwickler vertrauen öffentlichen Quellen oft, ohne deren Herkunft zu überprüfen. Zu den Risiken gehören:
- Nicht authentifizierte Pulls aus öffentlichen Container-Registrierungen
- Nicht signierte Bilder ohne Beweise dafür, wer sie gebaut hat
- Register von Drittanbietern mit schwachen Richtlinien, was zu manipulierten Basisbildern führt
Beispiel für unsicheres Verhalten:
Die Gefahr: Sie wissen nicht, wer es gebaut hat, wann und was sich darin befindet. Sicherer Ansatz:
Überprüfen Sie stets den Herausgeber, achten Sie auf kryptografische Integrität und bevorzugen Sie vertrauenswürdige offizielle Register. Die Annahme, dass jedes Docker-Register standardmäßig sicher ist, schafft blinde Flecken in der Lieferkette.
Durchsetzung der Bildherkunft mit Signaturen und Zugriffskontrolle
Um schädliche Docker-Images zu verhindern, müssen DevSecOps-Teams die Herkunft der Images überprüfen. Das bedeutet, dass die Authentizität überprüft werden muss, bevor ein Image in die Entwicklungs-, Staging- oder Produktionsumgebung gelangt. Zu den Best Practices gehören:
- Bildsignierung: Verwenden Sie Docker Content Trust oder Sigstore, um Bilder zu signieren
- RBAC-Richtlinien: Beschränken Sie, wer Push- oder Pull-Vorgänge aus einem Container-Registry ausführen kann
Bescheinigungen: Erfordert Metadaten, die beweisen, wie und wo ein Bild erstellt wurde. Beispiel mit Docker Content Trust:
Wenn die Vertrauensfunktion aktiviert ist, werden nicht signierte Images abgelehnt. In Kombination mit RBAC verhindert dies, dass betrügerische Benutzer vergiftete Builds in Ihre Docker-Registrierung einfügen.
Automatisieren von Bildsicherheitsprüfungen in CI/CD Pipelines
Die manuelle Überprüfung ist nicht skalierbar. Sicherheitsüberprüfungen müssen automatisiert werden, um schädliche Docker-Images zu blockieren, bevor sie sich verbreiten.
Techniken:
- Richtlinien-Engines: Tools wie OPA Gatekeeper erzwingen zulässige Registrierungen und Tags
- Sicherheitslücken-Scanner: Bilder automatisch auf bekannte CVEs analysieren
- Pipeline Wachen: Blockiert die Bereitstellung, wenn ein Bild die Signatur- oder Scananforderungen nicht erfüllt.
CI/CD Beispiel
Mini-Checkliste für Entwickler (CI/CD Registrierungssicherheit)
- Verwenden Sie niemals die neuesten Tags in der Produktion pipelines
- Nur aus vertrauenswürdigen Docker-Registries abrufen
- Erzwingen Sie die kryptografische Signatur für jedes Bild
- Scannen Sie Bilder beim Erstellen und Bereitstellen
- Nicht signierte oder nicht gescannte Bilder automatisch blockieren
Durch die Automatisierung von Prüfungen wird sichergestellt, dass Angreifer kein schädliches Docker-Image einschleusen können, während die Entwickler mit dem Programmieren beschäftigt sind.
Erstellen einer sicheren Docker-Registry-Strategie mit DevSecOps-Prinzipien
Ein gehärtetes Docker-Register ist mehr als ein Speichersystem; es ist Teil Ihrer Sicherheitsgrenze. Kernpraktiken:
- Beschränken Sie Push-/Pull-Vorgänge auf vertrauenswürdige Konten
- Segmentieren Sie Registrierungen nach Umgebung (Entwicklung, Staging, Produktion).
- Aktivieren Sie die Überwachungsprotokollierung für jede Registrierungsaktion
- Bereinigen Sie nicht verwendete Bilder regelmäßig, um die Angriffsfläche zu verringern
Ein Container-Register, das auf DevSecOps-Prinzipien stellt sicher, dass jedes Bild, das durch die pipeline ist kontrolliert, nachvollziehbar und gesichert.
Lösungen wie Xygeni Verbessern Sie dies durch die kontinuierliche Überwachung der Register und pipelines für nicht autorisierte oder manipulierte Bilder. Sie erzwingen guardrails Daher werden nur verifizierte Bilder bereitgestellt.
Sperren Ihrer Docker-Registrierung
Ihre Docker-Registrierung ist Teil Ihrer Angriffsfläche. Wenn Angreifer bösartige Docker-Images einschleusen, CI/CD pipeline kann zum Liefersystem für ihre Nutzlasten werden. Die Erkenntnisse für Entwickler sind klar:
- Vertrauen Sie nicht den Standardeinstellungen: Validieren Sie jede Bildquelle
- Pin-Versionen und vermeiden Sie die neuesten
- Automatisieren Sie Scans und setzen Sie Signaturrichtlinien durch
- Behandeln Sie Ihr Container-Registry als kritische Infrastruktur
Die Integration von Registry-Sicherheit in Ihren DevSecOps-Workflow reduziert das Risiko, dass sich manipulierte Builds unbemerkt in Umgebungen verbreiten. Tools wie Xygeni machen dies möglich, indem sie Einblick in versteckte Registry-Risiken bieten, Richtlinien durchsetzen und manipulierte Images erkennen, bevor sie live gehen. Beim Sperren Ihres Docker-Registers geht es nicht nur um die Speicherung, sondern um die Kontrolle Ihrer gesamten Container-Lieferkette. Entwickler, die Register als Sicherheitsgrenze betrachten, stoppen Angreifer, bevor sie die Laufzeit erreichen.
