Anleitung: Container-Images aktualisieren
Diese Anleitung beschreibt, wie gehärtete Container-Images regelmäßig und nachvollziehbar aktualisiert werden – und zeigt am Beispiel der ZenDiS-Imagegruppe, wie eine automatisierte Update-Pipeline in der Praxis aussehen kann.
Konzeptionelle Grundlage
Gehärtete Container-Images sind kein einmaliges Artefakt. Neue Versionen der enthaltenen Laufzeitkomponenten, Sicherheitspatches und CVE-Behebungen erfordern regelmäßige Aktualisierungen. Die Container Hardening Checklist empfiehlt, diesen Prozess so weit wie möglich zu automatisieren.
Das Ziel ist ein reproduzierbarer Ablauf:
- Neue Abhängigkeitsversionen werden automatisch erkannt.
- Ein Build wird ausgelöst.
- Automatisierte Tests prüfen das Ergebnis (vgl. Anleitung: Container-Images testen).
- Ein Mensch prüft und gibt den neuen Tag frei.
Werkzeug: Renovate
Renovate ist ein Open-Source-Tool zur automatischen Erkennung von Abhängigkeitsaktualisierungen. Es überwacht Repositories und öffnet automatisch Merge Requests, wenn neue Versionen verfügbar sind.
Für Container-Images bedeutet das: Renovate erkennt neue Tags des Basis-Images oder neue Versionen eingesetzter Komponenten und erstellt einen MR mit dem angepassten Build-Kontext.
Beispiel: ZenDiS-Imagegruppe
Die ZenDiS-Imagegruppe auf OpenCode verwaltet mehrere gehärtete Container-Images in einer gemeinsamen GitLab-Gruppe. Updates werden zentral über ein dediziertes Renovate-Projekt orchestriert.
Funktionsweise
Die Update-Konfiguration liegt dezentral: Jedes Image-Repository enthält eine eigene renovate.json, die definiert, welche Abhängigkeiten beobachtet und wie Update-MRs gestaltet werden sollen.
Das zentrale Renovate-Projekt übernimmt die Ausführung: Seine CI-Pipeline startet Renovate und richtet es auf alle Repositories der Gruppe aus. Renovate liest dabei die jeweilige renovate.json aus dem Ziel-Repository und handelt entsprechend.
Erkennt Renovate eine neue Version, öffnet es automatisch einen Merge Request im jeweiligen Image-Repository. Die dort hinterlegte CI-Pipeline baut das Image, führt die Smoke Tests aus und liefert das Testergebnis direkt im MR. Der Reviewer sieht auf einen Blick, ob das Update funktional unbedenklich ist.
Update-Helper für Nix-basierte Images
Für Images, die mit Nix gebaut werden, stellt die Container Hardening Workbench einen dedizierten Update-Helper bereit.
Empfehlungen für eigene Update-Prozesse
Automatisieren Sie die Erkennung, nicht die Übernahme. Renovate oder vergleichbare Werkzeuge sollten automatisch Merge Requests öffnen – die Freigabe bleibt beim Menschen. Tests geben dabei die Sicherheit, dass das Update funktional korrekt ist.
Koppeln Sie Updates und Tests. Ein Renovate-MR ohne laufende CI-Pipeline liefert keine Entscheidungsgrundlage. Stellen Sie sicher, dass jeder Update-MR automatisch einen vollständigen Build-und-Test-Durchlauf auslöst.