Container ist schwierig – Aikido Container macht es einfach

Container beginnt mit Ihrem Basisimage.
Aber hier ist der Haken:

• Ein einfaches Upgrade auf die „neueste“ Version eines Basis-Images kann Ihre Anwendung beschädigen.
• Sie sind gezwungen, sich zwischen dem Ausliefern bekannter Schwachstellen oder dem tagelangen Beheben von Kompatibilitätsproblemen zu entscheiden.
• Und oft... sind Sie sich nicht einmal sicher, ob sich ein Upgrade lohnt.

In diesem Beitrag untersuchen wir, warum das Aktualisieren von Basis-Images schwieriger ist, als es scheint, gehen reale Beispiele durch und zeigen, wie Sie sichere, intelligente Upgrades automatisieren können, ohne Ihre Anwendung zu beschädigen.

Das Problem: „Aktualisieren Sie einfach Ihr Basis-Image“ – Leichter gesagt als getan

Wenn Sie dies lesen, haben Sie wahrscheinlich etwas gegoogelt wie „Wie sichert man seine Container“, und der erste Punkt in jedem KI-generierten Schrottartikel, den Sie gelesen haben, ist dieser: aktualisieren Sie Ihr Basis-Image. Einfach, oder? Nun, nicht ganz so schnell. 

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

Sie führen einen Scan Ihres container durch und es wird eine CVE mit hohem Schweregrad gefunden. Die hilfreiche Empfehlung lautet, das Basis-Image zu aktualisieren – fantastisch, das haben Sie noch vor dem Mittagessen erledigt. 

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

„…aber Sie entdecken ein Problem.“ 

Durch blindes Upgrade von ubuntu:20.04 zu ubuntu:22.04, zerbricht Ihre Anwendung.

Schauen wir uns einige Beispiele an, wie ein Base Image aktualisiert wird und was in der Realität passiert. 

Beispiel 1: Ein Dockerfile, das nach einem Upgrade fehlschlägt

Initiales Dockerfile:

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 zu:

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 lässt sich nicht gegen neuere kompilieren libpq Header aktiviert Bücherwurm.
• flask==1.1.2 unterstützt nicht Python 3.11 Laufzeitfunktionen (veraltete APIs führen zu Fehlern).
• Der Build schlägt in CI fehl.
• Ihr Dev-Team ist verärgert und Ihr Mittagessen ist ruiniert. 

Beispiel 2: Base-Image-Upgrades, die subtile Laufzeitfehler einfü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:

• node:20 verwendet neuere OpenSSL Versionen — strenge TLS-Verifizierung führt bei älteren axios-Konfigurationen zu Problemen.
• Die App wirft UNABLE_TO_VERIFY_LEAF_SIGNATURE Laufzeitfehler HTTP Aufrufe an Legacy-Dienste.

Warum „latest“ eine Falle ist

Das Docker-Ökosystem fördert die Verwendung von neuesten Tags oder Top-Line-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 langsameren Entwicklung führt, da Sie Zeit mit der Fehlerbehebung verbringen. 

Die Lösung ist dann offensichtlich, auf eine getestete Minor-Version zu pinnen… Nicht so schnell, denn jetzt sind Sie in das Spiel des Security Whack-a-Mole eingetreten, wo Sie für immer neue CVEs entdecken werden, die Sie anfällig machen könnten. 

Entscheidungslähmung: Sollten Sie ein Upgrade durchführen oder nicht?

Sicherheitsteams drängen auf Upgrades.
Entwickelnde wehren sich aufgrund der Stabilität.

Wer hat Recht? Es kommt darauf an.

UM die Entscheidung überhaupt zu verstehen, müssen Sie alle Optionen prüfen, was bedeutet, eine riesige Tabelle mit allen Versionen, Sicherheitsrisiken, Stabilitätsrisiken und Verfügbarkeiten zu erstellen. 

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

Das führt zu komplexen, mangelhaften und unmöglichen Entscheidungen 

1. Bleiben Sie beim alten Image und akzeptieren Sie Schwachstellen.
2. Ihre App upgraden und dabei beschädigen, mit dem Risiko von Produktionsausfällen
3. Manuelle Kompatibilitätstests versuchen – tagelange Arbeit

Der manuelle Upgrade-Workflow:

Wenn Sie dies manuell tun, sieht es so aus:

• CVEs prüfen: trivy python:3.8-buster
• Jede CVE recherchieren: Ist sie im Kontext Ihrer Anwendung erreichbar?
• Über Upgrade-Kandidaten entscheiden 
• Testen Sie das neue Image:
  
  • Build
  • Führen Sie Unit-Tests aus
  • Führen Sie Integrationstests aus
• Im Fehlerfall versuchen Sie, Code zu patchen oder Bibliotheken zu aktualisieren.
• Wiederholen Sie dies für jeden container.

Es ist anstrengend.

Die Kosten des Stillstands

Sie denken vielleicht: “Never change a running system.”

Aber ungepatchte container tragen massiv zu Sicherheitsverletzungen bei „87 % der in der Produktion verwendeten container wiesen mindestens eine kritische oder schwerwiegende Schwachstelle auf.“ Quelle 

Es gibt auch viele bekannte Exploits, die in gängigen Basis-Images existieren. 

• Unzip Path Traversal Schwachstelle (CVE-2020-27350) — saß jahrelang in Millionen von Containern.
• Heartbleed (CVE-2014-0160) verblieben lange nach offiziellen Fixes in Legacy-Containern.
• PHP-FPM RCE (CVE-2019-11043) ermöglichen es Angreifern aus der Ferne, über manipulierte HTTP-Anfragen beliebigen Code auszuführen, und waren in container mit vorinstalliertes PHP-FPM bevor sie gepatcht werden

Wie unsere Auto-Fix-Funktion hilft

Um genau dieses Problem zu lösen, hat Aikido unsere Funktion container eingeführt, denn auch wir leiden unter diesem Problem. 

Die Funktion arbeitet wie folgt: Aikido Ihre Container auf Schwachstellen. Wenn (oder besser gesagt: sobald) wir Schwachstellen finden, benachrichtigen wir Sie wie immer und bieten Ihnen verschiedene Optionen an, anstatt Sie zu ermahnen, Ihr Basisimage zu aktualisieren. 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 Aktualisierung alle oder einen Großteil der hohen CVEs beseitigen kann, was bedeutet, dass dies ein angemessenes Upgrade des Basis-Images ist. 

Wenn das Upgrade ein kleiner Versionssprung ist, können Sie automatisch einen Pull Request erstellen, um die Version zu erhöhen. 

Das sind Stunden an Arbeit, die eingespart werden.

Fazit:

• Das Aktualisieren von container ist wirklich schwierig.
• Der Ratschlag „einfach upgraden“ vereinfacht einen komplexen, risikobehafteten Prozess zu stark.
• Ihre Teams sind zu Recht vorsichtig – aber sie sollten sich nicht zwischen Sicherheit und Stabilität entscheiden müssen.
• container Aikidoübernimmt die mühsame Arbeit für Sie, sodass Sie eine fundierte Entscheidung treffen können. 
• Wenn Sie also das nächste Mal eine Schwachstellenwarnung für Basis-Images sehen, werden Sie nicht in Panik geraten. Sie erhalten einen PR.