Kleine, sicherere Containerbilder

Lauf ! docker images Sie werden Bilder von 800 MB, 1 GB, manchmal mehr, für eine Anwendung finden, deren Code ein paar Megabyte beträgt. Der Rest ist ein komplettes Betriebssystem, Compiler, Paketmanager, Shell, Debugging-Tools und übriggebliebene Dateien.

Große Bilder brauchen länger, um zu bauen, zu ziehen und zu starten. Außerdem ist jedes zusätzliche Paket ein Sicherheitsrisiko. So mache ich meine kleiner und sicherer.

Mehrstufige Bauten

Der größte Sieg, bei weitem. Verwenden Sie eine Stufe mit allen Erstellungswerkzeugen, um Ihre App zu kompilieren, und kopieren Sie dann nur das Ergebnis in ein minimales Endbild.

# Build stage
FROM golang:1.25 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/server

# Final stage
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /app /app
USER nonroot
ENTRYPOINT ["/app"]

Das letzte Bild enthält die Binärzahl und fast nichts anderes. Keine Shell, kein Paketmanager, kein Compiler. Für eine Go-App kann das bedeuten, von etwa einem Gigabyte auf etwa zwanzig Megabyte zu gehen.

Das gleiche Muster funktioniert für andere Sprachen: Bauen Sie mit dem vollständigen SDK-Image, laufen Sie mit einem schlanken Laufzeit-Image.

Auswahl eines Basisbildes

Das Basisbild bestimmt die Größe Ihres Bildes und die Anzahl der Verwundbarkeiten.

• Vollständige Distributionsbilder (ubuntu, debian, node, python): bequem, groß, viele Pakete, die man nicht braucht.
• Schlanke Varianten (python:3.13-slim, node:22-slim): eine gute Mittelweg.
• Alpen: sehr klein, verwendet aber musl anstelle von glibc, was gelegentlich zu subtilen Kompatibilitäts- oder Leistungsproblemen führt.
• Nicht distro (Google): nur Ihre App und ihre Laufzeit-Abhängigkeiten. Keine Muschel.
• Verhärtetes Minimalbild: Chainguard Images (auf Wolfi basiert), Docker Hardened Images und ähnliche Angebote werden häufig neu erstellt und zielen auf Null oder nahezu Null bekannte Schwachstellen ab.

Eine Notiz zu Bitnami: viele Teams verließen sich auf Bitnamis kostenlose Containerbilder und Helm-Diagramme. Im Jahr 2025 änderte Broadcom den freien Katalog erheblich und verlegte die meisten Versionenbilder in ein älteres Repository, das keine Updates mehr erhält. Wenn Ihre Diagramme oder Dockerfiles noch auf Bitnami-Bilder verweisen, überprüfen Sie sie jetzt und wechseln Sie zu unterstützten Alternativen.

Jedes Paket in deinem Bild ist ein Paket, das du reparieren musst. Die leichteste Schwachstelle zu reparieren ist die, die Sie nie ausgeliefert haben.

Schnellerer Builds mit Caching

Docker baut Ebenen in der Reihenfolge auf und verwendet zwischengespeicherte Ebenen wieder, bis sich etwas ändert. Also zählt die Reihenfolge:

1. Kopieren Sie zuerst Abhängigkeitsdateien (package.json, go.mod, requirements.txt), Installation von Abhängigkeiten und dann Kopieren des Restcodes. Codeänderungen machen die Abhängigkeitsschicht nicht ungültig.
2. Verwenden Sie eine .dockerignore zu halten node_modules, .git, Testdaten und lokale Geheimnisse aus dem Kontext des Baus.
3. Verwenden Sie BuildKit-Cache-Halterungen für Caches des Paketmanagers:

RUN --mount=type=cache,target=/root/.cache/pip \
    pip install -r requirements.txt

4. Verwenden Sie die Cache-Datenbank in CI (--cache-to und --cache-from mit docker buildxDie Anlagen sind in der Regel mit einem hohen Gehalt an Rohrleitungen ausgestattet.

Prüfliste für die Härtung

• Führen Sie als Nicht-Root-Benutzer. Ausgestattet USER in der Dockerfile und runAsNonRoot: true in Kubernetes.
• Bilder der Pin-Basis Nach Version, idealerweise nach Verarbeitung, und lassen Sie Renovate sie aktualisieren.
• Keine Geheimnisse in Bildern. Verwenden Sie Baugrundlagen (--mount=type=secret) für alles, was zur Bauzeit benötigt wird.
• Lese-allein-Rot-Dateisystem in Kubernetes, wo möglich.
• Verlassen Sie Linux-Funktionen - Das brauchst du nicht.
• Hinzufügen von Etiketten für Quelle, Version und Betreuer (OCI-Anmerkungen).

Scannen vor dem Versand

Scannen Sie Bilder in CI und scheitern Sie beim Aufbau auf ernsthafte, behebliche Schwachstellen:

trivy image --severity HIGH,CRITICAL --ignore-unfixed \
  --exit-code 1 registry.example.com/shop-api:1.4.2

Trivy und Grippe sind beide ausgezeichnete Open-Source-Scanner. Docker Scout und die meisten Registrierungen scannen ebenfalls automatisch.

Zwei Tipps: --ignore-unfixed (oder ähnlich) so dass Sie nicht durch Schwachstellen blockiert werden, die niemand noch beheben kann, und wieder Scannen von Bildern regelmäßig, nicht nur bei der Erstellung Zeit, weil neue Schwachstellen in alten Bildern jeden Tag gefunden werden.

Also, wo fange ich an?

Nehmen Sie Ihr größtes Bild. Hinzu kommen ein mehrstufiges Bauen und eine schlanke oder distrolose Basis. Trivy vor und nach. Der Unterschied in Größe und Sicherheit ist normalerweise so groß, dass der Rest des Teams es auch will.

Meine Meinung: Versenden Sie Ihre App, nicht ein ganzes Betriebssystem. Kleinere Bilder sind schneller, billiger und sicherer, alles auf einmal.

Desly