Containerbau mit Kaniko

Die Automatisierung von Container-Imagebau-Prozessen startet in aller Regel mit dem direkten Portieren von docker build in eine CI-Pipeline. Dieser Befehl ist an den Docker Daemon des Hosts gerichtet, welcher als Socket in die Pipeline Sandbox gemounted wird.

Problematisch ist das vor allem, weil es erlaubt, aus der Pipeline heraus beliebige Prozesse auf dem Host zu starten, ggf. ohne weitere Isolation von ihrem Umfeld. Das macht die CI Pipeline zum Sicherheitsrisiko. Umgehen lässt sich dieses Problem auf mehreren Wegen, welche alle mit ihren Vor- und Nachteilen daherkommen:

• Der Docker Daemon selbst lässt sich in einem Container ausführen („Docker in Docker“). Die Pipeline spricht dann nur mit einem containerisierten Docker Daemon, was mehr Isolation verspricht. Problem hierbei ist vor allem, dass der Daemon Container weitreichende Kernelprivilegien benötigt, um seine Arbeit (im Wesentlichen das Starten weiterer Prozesse) verrichten zu können. Solche privilegierten Container gelten ihrerseits selbst als Sicherheitsrisiko, da man aus ihnen ausbrechen könnte.
• Durch das Ersetzen von Docker durch Buildah lässt sich auf den Docker Daemon vollständig verzichten. Der Buildah Container selbst muss aber trotzdem privilegiert laufen, um Prozesse in den zu bauenden Containern starten zu können.
• Beliebige Abwandlungen beider vorheriger Varianten durch andere Tools oder Config (z.B. „rootless Docker in Docker“, Docker mit Userspace Remapping, …).

Beide Lösungen benötigen privilegierte Container, welche u.A. in Kubernetes nicht akzeptabel sind. Eine Lösung ohne dieses Problem bietet Kaniko. Kaniko lässt sich in Docker, wie auch in Kubernetes betreiben und bietet eine containerisierte Umgebung zum Imagebau, ohne weitreichende Kernel-Capabilities zu benötigen.

Das Konzept hinter Kaniko

Da ein Kaniko Container nicht privilegiert läuft, funktioniert der Image Bauprozess im Container etwas anders als in Docker. Wesentlicher Unterschied ist hier, dass alle Phasen des Baus (Aufbau des Basis Filesystems, isoliertes Ausführen von Befehlen, Snapshotting des Filesystems) im User- statt im Systemspace stattfinden. Von Anwendungsseite merkt man hiervon allerdings nichts.

Die einzigen Unterschiede in der Bedienung kommen daher, dass ein Kaniko Container zum einmaligen Gebrauch – also zum Bau eines einzigen Images – gedacht ist. Danach sollte im Idealfall ein neuer Kaniko Container gestartet werden, um wieder in einer neuen sauberen Umgebung zu starten, denn Kaniko löscht das Filesystem alter Container nicht automatisch. Alternativ gibt es zum „Aufräumen“ im laufenden Kaniko mittlerweile aber auch eine Möglichkeit (siehe später), um den Bau mehrerer Images in einem Container zu ermöglichen. Best Practice in alter Kubernetes-Manier bleibt aber weiterhin „eine Aufgabe – ein Pod“.

Verwendung

Bauen und Pushen eines Container Images mit Kaniko

Im Gegensatz zu Docker, Buildah, etc. ist das offizielle Kaniko Container Image komplett minimalistisch aufgebaut. Insbesondere beinhaltet es keine Shell, weswegen alle Vorbereitungen zum Containerbau (auch das Bereitstellen von Container Registry Credentials) außerhalb von Kaniko stattfinden müssen. Ein typischer Build Ablauf zum Pushen in eine Docker Registry sieht daher so aus:

• Erstellen einer Docker config.json mit Credentials via