Zugangsdaten in Image-Layern

Was ist Zugangsdaten in Image-Layern?

Image-Layer lassen sich nur ergänzen. Ein Zugangstoken, das ein RUN-Befehl in einen Layer schreibt, bleibt dort erhalten, auch wenn ein späterer RUN-Befehl die Datei löscht. Die Datei fehlt im fertigen Container; das Token steht weiterhin in der Build-Historie. Sie laden ein öffentliches Image herunter, lesen den vollständigen Build-Befehl und prüfen die Rechte des Publish-Tokens. Danach widerrufen Sie es, stellen einen Ersatz mit begrenzten Rechten aus und ersetzen das Build-Argument durch einen BuildKit-Secret-Mount. So gelangt das neue Token in keinen ausgelieferten Layer.

Was Sie lernen in Zugangsdaten in Image-Layern

• Erklären Sie, warum Image-Layer unveränderlich sind und ein späterer RUN-Befehl zum Löschen einer Token-Datei den Wert in der Build-Historie nicht entfernt
• Lesen Sie ein im Image gespeichertes Token aus den vollständigen Layer-Befehlen aus, da die normale Verlaufsansicht die Spalte CREATED BY kürzt
• Widerrufen Sie zuerst das offengelegte Token und stellen Sie einen Ersatz mit begrenzten Rechten und begrenzter Gültigkeit aus, bevor Sie das Image ändern
• Wenden Sie einen BuildKit-Secret-Mount an, damit das Token während des Builds verfügbar ist, aber niemals in einen ausgelieferten Layer geschrieben wird
• Überprüfen Sie das neu gebaute Image, indem Sie die vollständige Layer-Historie lesen und sicherstellen, dass die Zugangsdaten nirgendwo mehr angezeigt werden

Zugangsdaten in Image-Layern — Trainingsschritte

1. Das Ziel einschätzen

   Today Bob is targeting Cindralt, a payments company whose checkout service ships as a container image. He starts where anyone can: the company's own container registry. A published image is a convenient thing to attack. It is the exact artifact running in production, and pulling it costs nothing.

2. Jeder kann das Image herunterladen

   Das Repository erlaubt anonymes Herunterladen. Viele Unternehmen entscheiden sich bewusst dafür; allein ist das keine Schwachstelle. Es bedeutet aber, dass Bob dasselbe Artefakt erhält wie Cindralts Build-Server.

3. Das Image herunterladen

   Bob lädt den Tag herunter, den die Registry als „latest“ ausweist. Auf seinem Rechner landet Byte für Byte das Image, das Cindralt in Produktion betreibt – einschließlich aller beim Build entstandenen Layer.

4. Die Build-Historie lesen

   Jedes Image enthält Informationen über die Befehle, mit denen es gebaut wurde. Bob muss den Container weder starten noch entpacken: Die Layer-Historie gehört zu den Metadaten des heruntergeladenen Images. Auf den ersten Blick wirkt der Build sorgfältig. Nach der Installation der Abhängigkeiten wurde sogar aufgeräumt.

5. Den vollständigen Befehl anzeigen

   Die Standardtabelle ist auf die Breite eines Terminals zugeschnitten und zeigt nicht alle Informationen. Bob lässt sich nur die Build-Befehle vollständig ausgeben. Der Installationsbefehl schrieb ein Zugangstoken in eine Konfigurationsdatei. Es ist noch immer in dem Layer enthalten, den dieser Befehl erzeugte.

6. Warum das Löschen nicht half

7. Rechte des Tokens prüfen

   Ein Zugangstoken ist so mächtig wie die Rechte, die es gewährt. Bob fragt beim Paketindex von Cindralt ab, wem es gehört und was es darf. Die Antwort ist schlimmer als Zugriff auf einen einzelnen Dienst: Das Token darf alle Pakete veröffentlichen, von denen Cindralts Builds abhängen, und es läuft nie ab.

8. Was dieses Token wert ist

   Bob muss Cindralts Server nicht erneut angreifen. Mit Veröffentlichungsrechten für alle internen Pakete könnte er eine manipulierte neue Version einer Bibliothek veröffentlichen. Spätere Builds würden sie beziehen.

9. The index flags the token

   Cindralts Paketindex protokolliert jede authentifizierte Anfrage. In der Nacht wurde das Token ci-publisher von einer Adresse aus genutzt, die weder Cindralt noch einem seiner Build-Runner gehört.

10. Am Image bestätigen

    Alice prüft die Behauptung selbst am veröffentlichten Image. Dafür braucht sie nur das, was auch Außenstehenden zur Verfügung steht: den öffentlichen Tag und einen gewöhnlichen Docker-Client.