Minimale Container-Images

Was ist Minimale Container-Images?

Ein Produktionsimage mit einem Paketmanager, einem Compiler, einer Shell und Netzwerkdienstprogrammen verwandelt einen begrenzten Anwendungsfehler in ein funktionierendes Toolkit. Der Angreifer bringt nichts; Das Bild wurde bereits versendet. Sie verwenden einen Befehl aus einem Checkout-Service-Bug, um Curl zu finden und die Anmeldeinformationen für die Instanzrolle vom Metadatenendpunkt unter 169.254.169.254 zu lesen. Dann teilen Sie den Build in zwei Phasen auf, kopieren nur das kompilierte Artefakt in ein finales Image ohne Distribution und beobachten, wie eine Shell im erneut bereitgestellten Container nicht geöffnet wird, weil keine vorhanden ist.

Was Sie lernen in Minimale Container-Images

• Erkennen Sie, dass eine Shell, ein Paketmanager, ein Compiler und Netzwerktools, die in einem Laufzeitimage enthalten sind, zum Werkzeugkasten eines Angreifers werden
• Verfolgen Sie, wie ein Befehl aus einem Anwendungsfehler das mitgelieferte Curl verwendet, um die Anmeldeinformationen der Instanzrolle von 169.254.169.254 zu lesen
• Konfigurieren Sie einen mehrstufigen Build, der die Build-Tools in der Build-Phase beibehält und nur das kompilierte Artefakt vorwärts kopiert
• Wenden Sie ein endgültiges Distroless-Image an und stellen Sie sicher, dass im erneut bereitgestellten Container keine Shell geöffnet werden kann
• Erklären Sie, wie das Entfernen der Shell und des Paketmanagers den einfachsten Weg von der eingeschränkten Codeausführung zur Kontrolle ebnet

Minimale Container-Images — Trainingsschritte

1. Ein Foothold im Checkout

   Bob beginnt nicht mit einer Shell. Der Checkout-Service erstellt PDF-Versandetiketten und ruft dafür eine Shell auf, und ein Feld in dieser Anfrage wird nicht bereinigt. Er injiziert eine Sonde, um zu bestätigen, dass er einen Befehl ausführen kann, und um zu sehen, wer und wo er ist.

2. Alles, was das Image mitbringt

   Bob hat als App eine Ein-Befehl-nach-dem-anderen-Ausführung, aber noch keine Shell. Das ist normalerweise der Punkt, an dem ein Angreifer feststeckt, es sei denn, der Container reicht ihm ein Toolkit. Bevor er etwas Auffälliges tut, prüft er, was bereits installiert ist.

3. Die Cloud-Credentials per curl abrufen

   Der Container läuft in der Cloud, und jede Cloud-Instanz stellt einen Metadaten-Dienst unter einer festen internen Adresse bereit, der die temporären Rollen-Credentials der Maschine ausgibt. Um ihn zu erreichen, braucht man einen HTTP-Client. Das Image hat einen mitgeliefert.

4. Wie ein Befehl zu einem Breach wurde

   Bobs Zugriff auf die App war stark eingeschränkt.

5. Eine Shell in einem Runtime-Container

   Skelwyn betreibt Endpoint Detection auf seinen Container-Hosts. Es weiß nicht, wofür jeder Container da ist; es meldet Verhalten, das nicht zu einer Runtime passt.

6. Bestätigen, was mitausgeliefert wurde

   Alice reproduziert, was der Angreifer vorgefunden hat: Sie fragt den laufenden Container, welche dieser Tools er tatsächlich enthält.

7. Eine 412-MB-Runtime

   Das Toolkit ist nicht kostenlos. Es ist Gewicht, und es ist Angriffsfläche. Alice prüft die Größe des Images, das der Service tatsächlich ausführt.

8. Wo das Toolkit hineinkommt

   Das Image wird aus einem einzigen Dockerfile gebaut. Alice öffnet es, um zu sehen, warum ein Runtime-Container am Ende einen Compiler mitführt.

9. Eine Stage, alles wird mitausgeliefert

   Das Image wird in einer einzigen Stage gebaut und ausgeführt, sodass die Runtime alles mitführt, was der Build benötigt.

10. Build von Runtime trennen

    Die Korrektur ist ein Multi-Stage-Build: Das vollständige Image mit seiner Toolchain bleibt als Build-Stage, die die App kompiliert, und anschließend werden nur die fertige App und ihre Abhängigkeiten in ein distroless Runtime-Image kopiert, das weder Shell noch Paketmanager noch Compiler besitzt.