Nicht nur für Minderprivilegierte

kaniko – Googles Build Tool für Docker Images in Kubernetes ohne Root-Zugriff

Marcel Richters
Kaniko

© Shutterstock.com / Ngukiaw

Für Docker-Images braucht es normalerweise Root-Zugriff. Das Tool kaniko von Google will dieses Problem lösen, indem ein Container erstellt wird, in dem die entsprechenden Rechte zur Verfügung gestellt werden. Das Ganze soll ohne Docker daemon oder privilegierte Zugriffsrechte funktionieren.

Um Images aus einer Standard-Dockerfile zu erstellen, benötigt es normalerweise interaktiven Zugriff auf einen Docker daemon, der selbst Root-Zugriff auf dem Rechner braucht, um ausgeführt werden zu können. Dadurch kann es schwierig werden, Images zu bauen, wenn ein Docker daemon nicht ohne Weiteres freigegeben werden kann – zum Beispiel in einem Kubernetes Cluster. Damit diese Umgebungen zukünftig keine Probleme mehr darstellen, hat Google jetzt das Open Source Tool kaniko vorgestellt.

Die Funktionsweise von kaniko

Mit kaniko sollen sich Containter Images auch ohne Root-Zugriff erstellen lassen. Das Tool kann dabei beides: Ein Image aus einem Dockerfile erstellen und es in eine Registry verschieben. Da keine Berechtigungen notwendig sind, soll sich kaniko in normalen Kubernetes Clustern, Google Kubernetes Engines oder jeder anderen Umgebung ohne Zugriff auf besondere Rechte oder einen Docker daemon ausführen lassen.

kaniko wird stattdessen als Container Image ausgeführt, in dem sich drei Parameter befinden. Das Dockerfile, der Build-Kontext und der Name der Registry, in der sich das endgültige Image befinden soll. Das Image wird komplett neu erstellt und enthält nur die Go Binary und eine Konfigurationsdatei, die zum Im- und Export von Images notwendig ist.

Die Architektur von kaniko / Quelle: Google

Der kaniko Executor kümmert sich darum, das Basis-Image-Dateisystem in die Root zu extrahieren. Die entsprechenden Befehle werden vom Executor ausgeführt, dieser erstellt nach jedem Befehl einen Snapshot des Dateisystems. Der Snapshot wird in dem Benutzerbereich erstellt, in dem das Dateisystem läuft und mit dem der vorherige Zustand verglichen wird, der sich im Speicher befindet. Alle Änderungen im Dateisystem werden an das Basis-Image angehängt, die relevanten Änderungen in den Metadaten des Bildes vorgenommen.

Die neu erstellten Images werden nach jedem ausgeführten Befehl in die gewünschte Regestry geschoben. Das Dateisystem wird komplett im Userspace innerhalb des Executor Images entpackt und ausgeführt, genauso wie dort auch die Snapshots erstellt werden. Dadurch ist ein privilegierter Zugriff auf den Rechner nicht notwendig. Weder Docker daemon noch CLI sind an dem Vorgang beteiligt.

Um kaniko in einem Standard-Kubernetes-Cluster auszuführen, sollten die Pod-Spezifikationen in etwa so aussehen, wie im Listing. Im Beispiel liefert ein Google Cloud Storage Bucket den Build-Kontext.

apiVersion: v1
kind: Pod
metadata:
 name: kaniko
spec:
 containers:
 - name: kaniko
   image: gcr.io/kaniko-project/executor:latest
   args: ["--dockerfile=<path to Dockerfile>",
           "--bucket=<GCS bucket>",
           "--destination=<gcr.io/$PROJECT/$REPO:$TAG"]
   volumeMounts:
     - name: kaniko-secret
       mountPath: /secret
   env:
     - name: GOOGLE_APPLICATION_CREDENTIALS
       value: /secret/kaniko-secret.json
 restartPolicy: Never
 volumes:
   - name: kaniko-secret
     secret:
       secretName: kaniko-secret

Zur Ausführung wird ein Kubernetes Secret benötigt, in dem sich die Authentifizierung für den Push des finalen Images in die Registry befindet. Für diesen Vorgang stellt Google eine entsprechende Anleitung im GitHub-Repository bereit.

kaniko im Google Cloud Container Builder

Um kaniko in einem Google Cloud Container Builder auszuführen, kann ein Build-Schritt hinzugefügt werden:

steps:
 - name: gcr.io/kaniko-project/executor:latest
   args: ["--dockerfile=<path to Dockerfile>",
          "--context=<path to build context>",
          "--destination=<gcr.io/[PROJECT]/[IMAGE]:[TAG]>"]

Das kaniko Executor Image baut und pusht das Image mit diesem Build-Schritt.

Andere Tools im Vergleich

Mit kaniko vergleichbare Tools sind etwa img und Orca-Build. Beide bauen Container-Images aus Dockerfiles, nutzen dafür allerdings unterschiedliche Ansätze. img führt den Build als Nutzer ohne Privilegien innerhalb eines Containers aus, während kaniko das als Administrator innerhalb eines Containers in unprivilegierter Umgebung tut. Orca-Build führt Builds aus, indem runc umhüllt wird, welches wiederum Kernel-Namespacing-Techniken verwendet, um RUN-Befehle auszuführen. kaniko soll das erreichen, indem Befehle als Root-Nutzer im Container ausgeführt werden.

Wer sich für das Tool interessiert, findet auch im entsprechenden Blog-Eintrag von Google alle notwendigen Informationen für den Einstieg.

Geschrieben von
Marcel Richters
Marcel Richters
Marcel hat Soziologie an der Goethe-Universität in Frankfurt am Main studiert und danach als E-Commerce-Manager gearbeitet. Seit Februar 2018 unterstützt er das Team von JAXenter als Redakteur. Daneben arbeitet er als freier Journalist in der Mainmetropole.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: