Image-Sicherheit - Amazon EKS
EmpfehlungenTools und Ressourcen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Image-Sicherheit

Sie sollten das Container-Image als erste Verteidigungslinie gegen einen Angriff betrachten. Ein unsicheres, schlecht aufgebautes Image kann es einem Angreifer ermöglichen, die Grenzen des Containers zu umgehen und sich Zugriff auf den Host zu verschaffen. Sobald sich ein Angreifer auf dem Host befindet, kann er Zugriff auf vertrauliche Informationen erhalten oder sich innerhalb des Clusters oder mit Ihrem AWS-Konto seitlich bewegen. Die folgenden bewährten Methoden tragen dazu bei, das Risiko eines solchen Vorfalls zu verringern.

Empfehlungen

Erstellen Sie ein Minimum an Bildern

Entfernen Sie zunächst alle überflüssigen Binärdateien aus dem Container-Image. Wenn Sie ein unbekanntes Bild von Dockerhub verwenden, überprüfen Sie das Bild mit einer Anwendung wie Dive, die Ihnen den Inhalt der einzelnen Ebenen des Containers anzeigen kann. Entfernen Sie alle Binärdateien mit den Bits SETUID und SETGID, da sie zur Erweiterung von Rechten verwendet werden können, und erwägen Sie, alle Shells und Hilfsprogramme wie nc und curl zu entfernen, die für schändliche Zwecke verwendet werden können. Sie können die Dateien mit den Bits SETUID und SETGID mit dem folgenden Befehl finden:

find / -perm /6000 -type f -exec ls -ld {} \;

Um die Sonderberechtigungen aus diesen Dateien zu entfernen, fügen Sie Ihrem Container-Image die folgende Direktive hinzu:

RUN find / -xdev -perm /6000 -type f -exec chmod a-s {} \; || true

Umgangssprachlich wird dies als De-Fanging Ihres Images bezeichnet.

Verwenden Sie mehrstufige Builds

Die Verwendung mehrstufiger Builds ist eine Möglichkeit, minimale Images zu erstellen. Oft werden mehrstufige Builds verwendet, um Teile des Continuous Integration-Zyklus zu automatisieren. Mehrstufige Builds können beispielsweise verwendet werden, um Ihren Quellcode zu verfälschen oder eine statische Codeanalyse durchzuführen. Dies bietet Entwicklern die Möglichkeit, nahezu sofortiges Feedback zu erhalten, anstatt auf die Ausführung einer Pipeline zu warten. Mehrstufige Builds sind aus Sicherheitsgründen attraktiv, da Sie damit die Größe des endgültigen Images minimieren können, das in Ihre Container-Registry übertragen wird. Container-Images ohne Build-Tools und andere überflüssige Binärdateien verbessern Ihre Sicherheitslage, indem sie die Angriffsfläche des Images reduzieren. Weitere Informationen zu mehrstufigen Builds finden Sie in der Dokumentation zu mehrstufigen Builds von Docker.

Erstellen Sie eine Softwareliste (SBOMs) für Ihr Container-Image

Eine „Softwareliste“ (SBOM) ist ein verschachteltes Inventar der Software-Artefakte, aus denen Ihr Container-Image besteht. SBOM ist ein wichtiger Baustein für Softwaresicherheit und Risikomanagement in der Software-Lieferkette. Das Generieren, Speichern von SBOMS in einem zentralen Repository und das Scannen SBOMs nach Sicherheitslücken trägt dazu bei, die folgenden Probleme auszuräumen:

  • Sichtbarkeit: Verstehen Sie, aus welchen Komponenten Ihr Container-Image besteht. Durch die Speicherung in einem zentralen Repository können SBOMs Sie jederzeit, auch nach der Implementierung, geprüft und gescannt werden, um neue Sicherheitslücken wie Zero-Day-Sicherheitslücken zu erkennen und darauf zu reagieren.

  • Überprüfung der Herkunft: Gewissheit, dass bestehende Annahmen darüber, woher und wie ein Artefakt stammt, wahr sind und dass das Artefakt oder die zugehörigen Metadaten während des Erstellungs- oder Bereitstellungsprozesses nicht manipuliert wurden.

  • Vertrauenswürdigkeit: Zusicherung, dass einem bestimmten Artefakt und seinem Inhalt das anvertraut werden kann, wofür es vorgegeben ist, d. h. dass es für einen bestimmten Zweck geeignet ist. Dazu gehört die Beurteilung, ob der Code sicher ausgeführt werden kann, und fundierte Entscheidungen über die mit der Ausführung des Codes verbundenen Risiken zu treffen. Die Vertrauenswürdigkeit wird durch die Erstellung eines bestätigten Pipeline-Ausführungsberichts zusammen mit einem bestätigten SBOM und einem beglaubigten CVE-Scanbericht gewährleistet, um den Benutzern des Images zu versichern, dass dieses Image tatsächlich auf sichere Weise (Pipeline) mit sicheren Komponenten erstellt wurde.

  • Vertrauensverifizierung durch Abhängigkeit: rekursive Überprüfung des Abhängigkeitsbaums eines Artefakts auf Vertrauenswürdigkeit und Herkunft der verwendeten Artefakte. Drift in SBOMs kann dabei helfen, böswillige Aktivitäten wie unbefugte, nicht vertrauenswürdige Abhängigkeiten und Infiltrationsversuche zu erkennen.

Die folgenden Tools können zur Generierung von SBOM verwendet werden:

  • Amazon Inspector kann zum Erstellen und Exportieren verwendet werden SBOMs.

  • Syft von Anchore kann auch für die SBOM-Generierung verwendet werden. Für schnellere Schwachstellenscans kann die für ein Container-Image generierte SBOM als Eingabe für den Scan verwendet werden. Die SBOM und der Scanbericht werden dann bestätigt und an das Bild angehängt, bevor das Bild zu Überprüfungs- und Auditzwecken an ein zentrales OCI-Repository wie Amazon ECR übertragen wird.

Weitere Informationen zur Sicherung Ihrer Software-Lieferkette finden Sie im CNCF-Leitfaden zu Best Practices für die Softwarelieferkette.

Scannen Sie Bilder regelmäßig auf Sicherheitslücken

Wie ihre Gegenstücke zu virtuellen Maschinen können Container-Images Binärdateien und Anwendungsbibliotheken mit Sicherheitslücken enthalten oder im Laufe der Zeit Sicherheitslücken entwickeln. Am besten schützen Sie sich vor Angriffen, indem Sie Ihre Images regelmäßig mit einem Image-Scanner überprüfen. Bilder, die in Amazon ECR gespeichert sind, können auf Push- oder On-Demand-Modus (einmal innerhalb von 24 Stunden) gescannt werden. ECR unterstützt derzeit zwei Arten des Scannens: Basic und Enhanced. Basic Scanning nutzt Clair, eine kostenlose Open-Source-Lösung zum Scannen von Bildern. Enhanced Scanning verwendet Amazon Inspector, um gegen Aufpreis automatische kontinuierliche Scans bereitzustellen. Nachdem ein Bild gescannt wurde, werden die Ergebnisse im EventBridge Event-Stream für den ECR-Eingang protokolliert. Sie können die Ergebnisse eines Scans auch von der ECR-Konsole aus sehen. Bilder mit der Sicherheitslücke HOCH oder KRITISCH sollten gelöscht oder neu erstellt werden. Wenn ein bereitgestelltes Image eine Schwachstelle aufweist, sollte es so schnell wie möglich ersetzt werden.

Für die Sicherheit Ihrer Umgebung ist es wichtig zu wissen, wo Images mit Sicherheitslücken bereitgestellt wurden. Es wäre zwar denkbar, eine Image-Tracking-Lösung selbst zu entwickeln, aber es gibt bereits mehrere kommerzielle Angebote, die diese und andere erweiterte Funktionen sofort bereitstellen, darunter:

Ein Kubernetes-Validierungs-Webhook könnte auch verwendet werden, um zu überprüfen, ob Images frei von kritischen Sicherheitslücken sind. Validierungs-Webhooks werden vor der Kubernetes-API aufgerufen. Sie werden in der Regel verwendet, um Anfragen abzulehnen, die nicht den im Webhook definierten Validierungskriterien entsprechen. Dies ist ein Beispiel für einen serverlosen Webhook, der die ECR describeImageScan Findings API aufruft, um festzustellen, ob ein Pod ein Bild mit kritischen Sicherheitslücken abruft. Wenn Sicherheitslücken gefunden werden, wird der Pod zurückgewiesen und eine Nachricht mit einer Liste von CVEs wird als Ereignis zurückgegeben.

Verwenden Sie Bescheinigungen, um die Integrität von Artefakten zu überprüfen

Eine Bescheinigung ist eine kryptografisch signierte „Aussage“, die behauptet, dass etwas — ein „Prädikat“, z. B. ein Pipeline-Lauf, die SBOM oder der Schwachstellenscan-Bericht — wahr ist, und zwar über ein „Subjekt“, d. h. das Container-Image.

Mithilfe von Bescheinigungen können Benutzer überprüfen, ob ein Artefakt aus einer vertrauenswürdigen Quelle in der Software-Lieferkette stammt. Beispielsweise können wir ein Container-Image verwenden, ohne alle Softwarekomponenten oder Abhängigkeiten zu kennen, die in diesem Image enthalten sind. Wenn wir jedoch den Aussagen des Herstellers des Container-Images über die vorhandene Software vertrauen, können wir die Bescheinigung des Herstellers verwenden, um uns auf dieses Artefakt zu verlassen. Das bedeutet, dass wir das Artefakt sicher in unserem Arbeitsablauf verwenden können, anstatt die Analyse selbst durchgeführt zu haben.

Erstellen Sie IAM-Richtlinien für ECR-Repositorys

Heutzutage ist es nicht ungewöhnlich, dass ein Unternehmen mehrere Entwicklungsteams hat, die unabhängig voneinander innerhalb eines gemeinsamen AWS-Kontos arbeiten. Wenn diese Teams keine Ressourcen gemeinsam nutzen müssen, sollten Sie eine Reihe von IAM-Richtlinien erstellen, die den Zugriff auf die Repositorys einschränken, mit denen jedes Team interagieren kann. Eine gute Möglichkeit, dies zu implementieren, ist die Verwendung von ECR-Namespaces. Namespaces sind eine Möglichkeit, ähnliche Repositorys zu gruppieren. Beispielsweise kann allen Registern für Team A das Präfix team-a/ vorangestellt werden, während denen für Team B das Präfix team-b/ verwendet werden kann. Die Richtlinie zur Zugriffsbeschränkung könnte wie folgt aussehen:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPushPull",
      "Effect": "Allow",
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability",
        "ecr:PutImage",
        "ecr:InitiateLayerUpload",
        "ecr:UploadLayerPart",
        "ecr:CompleteLayerUpload"
      ],
      "Resource": [
        "arn:aws:ecr:<region>:<account_id>:repository/team-a/*"
      ]
    }
  ]
}

Erwägen Sie die Verwendung von privaten ECR-Endpunkten

Die ECR-API hat einen öffentlichen Endpunkt. Folglich kann über das Internet auf ECR-Register zugegriffen werden, sofern die Anfrage von IAM authentifiziert und autorisiert wurde. Für Benutzer, die in einer Sandbox-Umgebung arbeiten müssen, in der die Cluster-VPC kein Internet Gateway (IGW) hat, können Sie einen privaten Endpunkt für ECR konfigurieren. Wenn Sie einen privaten Endpunkt erstellen, können Sie über eine private IP-Adresse privat auf die ECR-API zugreifen, anstatt den Datenverkehr über das Internet weiterzuleiten. Weitere Informationen zu diesem Thema finden Sie unter VPC-Endpoints mit Amazon ECR Interface.

Implementieren Sie Endpunktrichtlinien für ECR

Die Standard-Endpunktrichtlinie für ermöglicht den Zugriff auf alle ECR-Repositorys innerhalb einer Region. Dies könnte es einem ermöglichen, Daten attacker/insider zu exfiltrieren, indem sie als Container-Image verpackt und in eine Registrierung in einem anderen AWS-Konto übertragen werden. Um dieses Risiko zu minimieren, müssen Sie eine Endpunktrichtlinie erstellen, die den API-Zugriff auf ECR-Repositorys einschränkt. Die folgende Richtlinie ermöglicht es beispielsweise allen AWS-Prinzipien in Ihrem Konto, alle Aktionen gegen Ihre und nur gegen Ihre ECR-Repositorys durchzuführen:

{
  "Statement": [
    {
      "Sid": "LimitECRAccess",
      "Principal": "*",
      "Action": "*",
      "Effect": "Allow",
      "Resource": "arn:aws:ecr:<region>:<account_id>:repository/*"
    }
  ]
}

Sie können dies weiter verbessern, indem Sie eine Bedingung festlegen, die das neue PrincipalOrgID Attribut verwendet, wodurch verhindert pushing/pulling wird, dass Bilder nach einem IAM-Prinzip, das nicht Teil Ihrer AWS-Organisation ist, erstellt werden. Weitere Informationen finden Sie unter aws: PrincipalOrg ID. Wir haben empfohlen, dieselbe Richtlinie sowohl auf die com.amazonaws.<region>.ecr.dkr- als auch die com.amazonaws.<region>.ecr.api-Endpunkte anzuwenden. Da EKS Images für kube-proxy, coredns und aws-node aus ECR bezieht, müssen Sie die Konto-ID der Registrierung hinzufügen, z. B. zur Liste der Ressourcen in der Endpunktrichtlinie, oder die Richtlinie ändern, 602401143452.dkr.ecr.us-west-2.amazonaws.com/ um Pulls von Ihrer Konto-ID zuzulassen und Pushs auf diese zu beschränken. Die folgende Tabelle zeigt die Zuordnung zwischen den AWS-Konten, von denen EKS-Images verkauft werden, und der Cluster-Region.

Account Number (Kontonummer) Region

602401143452

Alle Handelsregionen mit Ausnahme der unten aufgeführten

—

—

800184023465

ap-east-1 - Asien-Pazifik (Hongkong)

558608220178

me-south-1 - Naher Osten (Bahrain)

918309763551

cn-north-1 - China (Peking)

961992271922

cn-northwest-1 - China (Ningxia)

Weitere Informationen zur Verwendung von Endpunktrichtlinien finden Sie unter Verwenden von VPC-Endpunktrichtlinien zur Steuerung des Amazon ECR-Zugriffs.

Implementieren Sie Lebenszyklusrichtlinien für ECR

Der NIST Application Container Security Guide warnt vor dem Risiko „veralteter Images in Registern“ und weist darauf hin, dass alte Images mit anfälligen out-of-date Softwarepaketen im Laufe der Zeit entfernt werden sollten, um eine versehentliche Bereitstellung und Offenlegung zu verhindern. Jedes ECR-Repository kann über eine Lebenszyklusrichtlinie verfügen, die Regeln dafür festlegt, wann Images ablaufen. In der offiziellen AWS-Dokumentation wird beschrieben, wie Testregeln eingerichtet, bewertet und anschließend angewendet werden. In den offiziellen Dokumenten finden Sie mehrere Beispiele für Lebenszyklusrichtlinien, die verschiedene Möglichkeiten zum Filtern der Bilder in einem Repository zeigen:

  • Filterung nach Alter oder Anzahl der Bilder

  • Filterung nach markierten oder nicht markierten Bildern

  • Filterung nach Bild-Tags, entweder in mehreren Regeln oder in einer einzigen Regel

??? + Warnung Wenn das Image einer Anwendung mit langer Laufzeit aus ECR gelöscht wird, kann dies zu Fehlern beim Abrufen des Images führen, wenn die Anwendung erneut bereitgestellt oder horizontal skaliert wird. Achten Sie bei der Verwendung von Image-Lebenszyklusrichtlinien darauf, dass Sie über CI/CD bewährte Verfahren verfügen, um Bereitstellungen und die Images, auf die sie verweisen, auf dem neuesten Stand zu halten, und immer Ablaufregeln für [Image] zu erstellen, die berücksichtigen, wie oft Sie Releases/Bereitstellungen durchführen.

Eine Reihe von kuratierten Images erstellen

Anstatt es Entwicklern zu ermöglichen, ihre eigenen Images zu erstellen, sollten Sie erwägen, eine Reihe von geprüften Images für die verschiedenen Anwendungsstapel in Ihrem Unternehmen zu erstellen. Auf diese Weise können Entwickler darauf verzichten, zu lernen, wie man Dockerfiles erstellt, und sich auf das Schreiben von Code konzentrieren. Wenn Änderungen in Master zusammengeführt werden, kann eine CI/CD Pipeline das Asset automatisch kompilieren, in einem Artefakt-Repository speichern und das Artefakt in das entsprechende Image kopieren, bevor es in eine Docker-Registry wie ECR übertragen wird. Zumindest sollten Sie eine Reihe von Basis-Images erstellen, aus denen Entwickler ihre eigenen Dockerfiles erstellen können. Im Idealfall sollten Sie vermeiden, Bilder aus Dockerhub abzurufen, da Sie zu einem Teil nicht immer wissen, was im Image enthalten ist und zum anderen etwa ein Fünftel der 1000 besten Images Sicherheitslücken aufweist. Eine Liste dieser Images und ihrer Sicherheitslücken finden Sie hier.

Fügen Sie die USER-Direktive zu Ihren Dockerfiles hinzu, um sie als Nicht-Root-Benutzer auszuführen

Wie im Abschnitt zur Pod-Sicherheit erwähnt, sollten Sie es vermeiden, den Container als Root auszuführen. Sie können dies zwar als Teil der PodSpec konfigurieren, es ist jedoch eine gute Angewohnheit, die USER Direktive für Ihre Dockerfiles zu verwenden. Die USER Direktive legt die UID fest, die beim Ausführen verwendet werden soll, oder die CMD Anweisung RUNENTRYPOINT, die nach der USER-Direktive erscheint.

Linten Sie Ihre Dockerfiles

Linting kann verwendet werden, um zu überprüfen, ob Ihre Dockerfiles einer Reihe von vordefinierten Richtlinien entsprechen, z. B. der Aufnahme der USER Direktive oder der Anforderung, dass alle Bilder markiert werden müssen. dockerfile_lint ist ein Open-Source-Projekt von, RedHat das gängige Best Practices verifiziert und eine Regel-Engine enthält, mit der Sie Ihre eigenen Regeln für das Linting von Dockerfiles erstellen können. Es kann in eine CI-Pipeline integriert werden, sodass Builds mit Dockerfiles, die gegen eine Regel verstoßen, automatisch fehlschlagen.

Erstellen Sie Bilder von Grund auf

Die Reduzierung der Angriffsfläche Ihrer Container-Images sollte das Hauptziel bei der Erstellung von Images sein. Der ideale Weg, dies zu tun, besteht darin, möglichst wenige Images ohne Binärdateien zu erstellen, mit denen Sicherheitslücken ausgenutzt werden können. Zum Glück verfügt Docker über einen Mechanismus, aus dem Bilder erstellt werden können. scratch Mit Sprachen wie Go können Sie eine statische verknüpfte Binärdatei erstellen und in Ihrem Dockerfile darauf verweisen, wie in diesem Beispiel:

############################
# STEP 1 build executable binary
############################
FROM golang:alpine AS builder# Install git.
# Git is required for fetching the dependencies.
RUN apk update && apk add --no-cache gitWORKDIR $GOPATH/src/mypackage/myapp/COPY . . # Fetch dependencies.
# Using go get.
RUN go get -d -v# Build the binary.
RUN go build -o /go/bin/hello

############################
# STEP 2 build a small image
############################
FROM scratch# Copy our static executable.
COPY --from=builder /go/bin/hello /go/bin/hello# Run the hello binary.
ENTRYPOINT ["/go/bin/hello"]

Dadurch wird ein Container-Image erstellt, das nur aus Ihrer Anwendung besteht, was es extrem sicher macht.

Verwenden Sie unveränderliche Tags mit ECR

Unveränderliche Tags zwingen Sie, das Image-Tag bei jedem Push in das Image-Repository zu aktualisieren. Dadurch kann verhindert werden, dass ein Angreifer ein Bild mit einer bösartigen Version überschreibt, ohne die Bild-Tags zu ändern. Darüber hinaus bietet es Ihnen die Möglichkeit, ein Bild einfach und eindeutig zu identifizieren.

Signieren Sie Ihre Bilder SBOMs, Pipeline-Läufe und Schwachstellenberichte

Als Docker zum ersten Mal eingeführt wurde, gab es kein kryptografisches Modell zur Überprüfung von Container-Images. Mit Version 2 fügte Docker dem Image-Manifest Digests hinzu. Dadurch konnte die Konfiguration eines Images gehasht und der Hash verwendet werden, um eine ID für das Image zu generieren. Wenn die Image-Signierung aktiviert ist, verifiziert die Docker-Engine die Signatur des Manifests und stellt so sicher, dass der Inhalt aus einer vertrauenswürdigen Quelle stammt und keine Manipulation stattgefunden hat. Nach dem Herunterladen jeder Ebene überprüft die Engine den Digest der Ebene und stellt sicher, dass der Inhalt mit dem im Manifest angegebenen Inhalt übereinstimmt. Mit der Bildsignierung können Sie effektiv eine sichere Lieferkette einrichten, indem die mit dem Bild verknüpften digitalen Signaturen überprüft werden.

Wir können AWS Signer oder Sigstore Cosign verwenden, um Container-Images zu signieren, Bescheinigungen zu erstellen, Schwachstellen-Scan-Berichte und SBOMs Pipeline-Run-Berichte zu erstellen. Diese Bescheinigungen gewährleisten die Vertrauenswürdigkeit und Integrität des Images, d. h., dass es tatsächlich von der vertrauenswürdigen Pipeline ohne jegliche Eingriffe oder Manipulationen erstellt wurde und dass es nur die Softwarekomponenten enthält, die dokumentiert sind (in der SBOM), die vom Herausgeber des Images verifiziert und als vertrauenswürdig eingestuft wurden. Diese Bescheinigungen können an das Container-Image angehängt und in das Repository übertragen werden.

Im nächsten Abschnitt werden wir sehen, wie die beglaubigten Artefakte für Audits und die Überprüfung durch die Zulassungsbehörden verwendet werden können.

Überprüfung der Bildintegrität mithilfe des Kubernetes Admission Controllers

Wir können Bildsignaturen und bestätigte Artefakte auf automatisierte Weise überprüfen, bevor wir das Image mithilfe des Dynamic Admission Controllers auf dem Ziel-Kubernetes-Cluster bereitstellen. Bereitstellungen können nur zugelassen werden, wenn die Sicherheitsmetadaten der Artefakte den Richtlinien des Zugangscontrollers entsprechen.

Wir können beispielsweise eine Richtlinie schreiben, die die Signatur eines Images kryptografisch verifiziert, eine bescheinigte SBOM, einen bescheinigten Pipeline-Run-Bericht oder einen beglaubigten CVE-Scanbericht. Wir können Bedingungen in die Richtlinie schreiben, um Daten im Bericht zu überprüfen, z. B. sollte ein CVE-Scan keine kritischen Daten enthalten. CVEs Die Bereitstellung ist nur für Bilder zulässig, die diese Bedingungen erfüllen. Alle anderen Bereitstellungen werden vom Zulassungskontrolleur abgelehnt.

Zu den Beispielen für den Zugangscontroller gehören:

Aktualisieren Sie die Pakete in Ihren Container-Images

Sie sollten RUN apt-get update && apt-get upgrade in Ihre Dockerfiles aufnehmen, um die Pakete in Ihren Images zu aktualisieren. Für das Upgrade müssen Sie zwar als Root ausführen, dies geschieht jedoch während der Image-Erstellungsphase. Die Anwendung muss nicht als Root-Benutzer ausgeführt werden. Sie können die Updates installieren und dann mit der USER-Direktive zu einem anderen Benutzer wechseln. Wenn Ihr Basis-Image nicht als Root-Benutzer ausgeführt wird, wechseln Sie zu Root und zurück. Verlassen Sie sich bei der Installation der neuesten Sicherheitsupdates nicht ausschließlich auf die Betreuer des Basis-Images.

Führen Sie apt-get clean den Befehl aus, um die Installationsdateien von zu löschen. /var/cache/apt/archives/ Sie können das Programm auch rm -rf /var/lib/apt/lists/* nach der Installation von Paketen ausführen. Dadurch werden die Indexdateien oder die Listen der Pakete entfernt, die zur Installation verfügbar sind. Beachten Sie, dass diese Befehle für jeden Paketmanager unterschiedlich sein können. Zum Beispiel:

RUN apt-get update && apt-get install -y \
    curl \
    git \
    libsqlite3-dev \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

Tools und Ressourcen