Warum die Aktualisierung von Container-Basisabbildern so schwierig ist (und wie man es einfacher machen kann)

Die Sicherheit von Containern beginnt mit dem Basis-Image.
Aber hier ist der Haken an der Sache:

• Ein einfaches Upgrade auf die "neueste" Version eines Basis-Images kann Ihre Anwendung zerstören.
• Sie müssen sich entscheiden, ob Sie bekannte Schwachstellen ausliefern oder Tage damit verbringen, Kompatibilitätsprobleme zu beheben.
• Und oft ist man sich nicht einmal sicher, ob sich ein Upgrade lohnt.

In diesem Beitrag gehen wir der Frage nach, warum das Aktualisieren von Basis-Images schwieriger ist, als es scheint, und zeigen anhand realer Beispiele, wie Sie sichere, intelligente Upgrades automatisieren können, ohne Ihre Anwendung zu zerstören.

Das Problem: "Aktualisieren Sie einfach Ihr Basisimage" - Leichter gesagt als getan

Wenn Sie dies lesen, haben Sie wahrscheinlich etwas gegoogelt wie "How to secure your containers" und der erste Punkt in jedem KI-generierten Slop-Artikel, den Sie gelesen haben, ist dieser: Aktualisieren Sie Ihr Basisimage. Einfach, oder? Nun, nicht so schnell. 

Ihr Basis-Image ist Ihr zentraler Sicherheitspunkt. Wenn Ihr Basis-Image Schwachstellen aufweist, trägt Ihre Anwendung diese Schwachstellen mit sich. Lassen Sie uns dieses Szenario durchspielen. 

Sie führen einen Scan gegen Ihr Container-Image durch und es wird ein CVE mit hohem Schweregrad gefunden. Die hilfreiche Empfehlung ist, das Basis-Image zu aktualisieren, fantastisch, Sie werden vor dem Mittagessen fertig sein. 

⚠️ CVE-2023-37920 gefunden in ubuntu:20.04
Schweregrad: Hoch
Behoben in: 22.04
Empfehlung: Basis-Image aktualisieren

...aber Sie entdecken ein Problem. 

Durch die blinde Aufrüstung von ubuntu:20.04 zu ubuntu:22.04zerbricht Ihre Bewerbung.

Sehen wir uns einige Beispiele für das Bumping eines Basisbildes an und was in der Realität passiert. 

Beispiel 1: Eine Dockerdatei, die nach einem Upgrade nicht mehr funktioniert

Initiale Dockerdatei:

FROM python:3.8-buster‍
RUN apt-get update && apt-get install -y libpq-dev
RUN pip install psycopg2==2.8.6 flask==1.1.2
COPY . /appCMD ["python", "app.py"]

Das Team rüstet auf:

FROM python:3.11-bookworm‍
RUN apt-get update && apt-get install -y libpq-dev
RUN pip install psycopg2==2.8.6 flask==1.1.2COPY . /appCMD ["python", "app.py"]

Ergebnis:

• psycopg2==2.8.6 kompiliert nicht gegen neuere libpq Überschriften zu Bücherwurm.
• Kolben==1.1.2 unterstützt nicht Python 3.11 Laufzeitfunktionen (veraltete APIs brechen).
• Der Build bricht im CI ab.
• Ihr Entwicklungsteam ist sauer und Ihr Mittagessen ist ruiniert. 

Beispiel 2: Basis-Image-Upgrades, die zu subtilen Laufzeitfehlern führen

Original:

FROM node:14-busterCOPY. /app
RUN npm ci
CMD ["node", "server.js"]

Upgrade auf:

FROM node:20-bullseye
COPY . /app
RUN npm ci
CMD ["node", "server.js"]

Laufzeitproblem:

• Knotenpunkt:20 verwendet neuere OpenSSL Versionen - die strenge TLS-Verifizierung bricht ältere axios-Konfigurationen.
• Die App wirft NICHT_ÜBERPRÜFBARE_BLATTSIGNATUR Fehler zur Laufzeit HTTP Anrufe bei bestehenden Diensten.

Warum "das Neueste" eine Falle ist

Das Docker-Ökosystem ermutigt zur Verwendung der neuesten Tags oder Top-Releases. Dies bedeutet jedoch oft, dass Ihre Anwendung, die am Montag noch lief, am Dienstag plötzlich ausfällt. Dies ist oft eine Falle, die zu Kopfschmerzen, Ausfällen und einer Verlangsamung der Entwicklung führt, da Sie Zeit mit der Behebung von Fehlern verbringen. 

Die Lösung besteht also darin, auf eine kleinere Version zu setzen, die Sie getestet haben.... Nicht so schnell, denn jetzt sind Sie in ein Sicherheits-Whack-a-mole-Spiel geraten, bei dem Sie ständig neue CVEs entdecken, die Sie angreifbar machen könnten. 

Entscheidungslähmung: Sollen Sie aufrüsten oder nicht?

Die Sicherheitsteams drängen auf Upgrades.
Die Entwickler halten sich wegen der Stabilität zurück.

Wer hat Recht? Das kommt darauf an.

ABER, um die Entscheidung überhaupt verstehen zu können, müssen Sie alle Optionen prüfen, was bedeutet, dass Sie eine umfangreiche Tabelle mit allen Versionen, Sicherheitsrisiken, Stabilitätsrisiken und der Verfügbarkeit erstellen müssen. 

Werfen wir einen Blick darauf, wie das aussehen könnte. 

Dies lässt Ihnen komplexe, beschissene und unmögliche Möglichkeiten 

1. Beim alten Image bleiben und Schwachstellen akzeptieren
2. Aktualisieren Sie Ihre Anwendung und riskieren Sie Produktionsausfälle.
3. Versuch einer manuellen Kompatibilitätsprüfung - tagelange Arbeit

Der manuelle Upgrade-Workflow:

Wenn Sie dies mit der Hand machen, sieht es folgendermaßen aus:

• CVEs überprüfen: trivy image python:3.8-buster
• Untersuchen Sie jedes CVE: Ist es in Ihrem Anwendungskontext erreichbar?
• Entscheiden Sie sich für einen Upgrade-Kandidaten 
• Testen Sie das neue Bild:
  
  • Bauen Sie
  • Einheitstests durchführen
  • Integrationstests durchführen
• Wenn dies nicht gelingt, versuchen Sie, den Code zu patchen oder die Bibliotheken zu aktualisieren.
• Wiederholen Sie dies für jeden Behälter.

Es ist anstrengend.

Die Kosten des Stillhaltens

Man könnte meinen, "was nicht kaputt ist, sollte man nicht reparieren".

Aber ungepatchte Container-CVEs tragen massiv zu Sicherheitsverletzungen bei: "87 % der Container-Images, die in der Produktion eingesetzt werden, wiesen mindestens eine kritische oder hochgefährliche Schwachstelle auf." Quelle 

Es gibt auch viele bekannte Schwachstellen in gängigen Basisbildern. 

• Unzip Path Traversal Sicherheitslücke (CVE-2020-27350) - saßen jahrelang in Millionen von Containern.
• Heartbleed (CVE-2014-0160) blieben noch lange nach den offiziellen Korrekturen in den alten Containern.
• PHP-FPM RCE (CVE-2019-11043) erlauben entfernten Angreifern die Ausführung von beliebigem Code über manipulierte HTTP-Anfragen und waren extrem häufig in Container-Basis-Images mit vorinstalliertes PHP-FPM bevor sie gepatcht werden

Wie unsere Auto-Fix-Funktion hilft

Um genau dieses Szenario zu lösen, hat Aikido Security unsere Container-Autofix-Funktion eingeführt, denn auch wir haben mit diesem Problem zu kämpfen. 

Die Funktion funktioniert wie folgt: Aikido scannt Ihre Container auf Schwachstellen. Wenn (oder eher wenn) wir Schwachstellen finden, warnen wir Sie wie immer. Anstatt Sie anzuschreien, Ihr Basis-Image zu aktualisieren, bieten wir Ihnen verschiedene Optionen an. Wir erstellen eine Tabelle, aus der Sie ersehen können, welche Version des Basis-Images welche CVEs behebt. Auf diese Weise können Sie sehr schnell erkennen, dass eine geringfügige Verbesserung alle oder einen Großteil der hohen CVEs beseitigen kann, was bedeutet, dass dies ein angemessenes Upgrade des Basis-Images ist. 

Wenn es sich bei dem Upgrade um eine geringfügige Änderung handelt, können Sie automatisch einen Pull-Request erstellen, um die Version zu erhöhen. 

Das spart Stunden an Arbeit

Schlussfolgerung:

• Das Aktualisieren von Container-Basis-Images ist wirklich schwierig.
• Der Ratschlag "einfach aufrüsten" vereinfacht einen komplexen, risikobehafteten Prozess zu sehr.
• Ihre Teams haben Recht, vorsichtig zu sein - aber sie sollten nicht zwischen Sicherheit und Stabilität wählen müssen.
• Der Container-Autofix von Aikido nimmt Ihnen die schwere Arbeit ab, damit Sie eine fundierte Entscheidung treffen können. 
• Wenn Sie also das nächste Mal eine Warnung über eine Sicherheitslücke im Basisbild sehen, werden Sie nicht in Panik geraten. Sie werden eine PR bekommen.

‍