Buildah vs Kaniko: Rootless Container Images in CI/CD im Vergleich 2026

Wer Container-Images in einer CI/CD-Pipeline baut, kommt traditionell an Docker nicht vorbei — doch docker build im Container setzt einen privilegierten Docker-Daemon voraus. Das ist ein erhebliches Sicherheitsrisiko, besonders in Kubernetes-Pipelines. Buildah (Red Hat) und Kaniko (Google) lösen dieses Problem auf unterschiedliche Weisen: beide bauen OCI-konforme Container-Images ohne Root-Rechte und ohne Docker-Daemon. Dieser Vergleich zeigt, wann welches Tool die bessere Wahl ist.

Das Problem: Docker-in-Docker ist ein Sicherheitsrisiko

Das klassische docker build in CI/CD erfordert Zugriff auf den Docker-Socket (/var/run/docker.sock). Wer diesen Socket in einen CI-Pod einhängt, gibt dem Container Root-Äquivalenz über den gesamten Kubernetes-Node — ein bekanntes Angriffsziel.

Docker-in-Docker (DinD) als privilegierter Sidecar ist kaum besser: Der Sidecar-Container läuft als privileged: true, was ebenfalls Node-Eskalation ermöglicht.

Buildah und Kaniko sind die wichtigsten Antworten der Cloud-Native-Welt auf dieses Problem.

Was ist Buildah?

Buildah ist ein CLI-Tool von Red Hat zum Erstellen von OCI/Docker-Images ohne Daemon. Es ist Teil der containers/buildah-Toolchain (zusammen mit Podman und Skopeo) und nutzt Linux User Namespaces für rootless Builds.

Stärken von Buildah:

  • Vollständig Open Source (Apache 2.0)
  • Rootless-Betrieb via Linux User Namespaces
  • Direkte Manipulation von Image-Layern (ohne Dockerfile)
  • Kompatibel mit Podman, Skopeo und dem gesamten containers-Ökosystem
  • Native Integration in RHEL/CentOS/Fedora-Umgebungen
  • Eigene Skript-API (buildah from, buildah run, buildah commit)
  • Unterstützt Dockerfile und eigene Build-Scripte (Shell/Bash)

Schwächen von Buildah:

  • Erfordert UserNS-Unterstützung im Kernel (Linux 4.18+)
  • In einigen Kubernetes-Deployments komplizierter zu konfigurieren als Kaniko
  • Weniger verbreitet in Cloud-CI-Systemen (GitHub Actions, GitLab CI)

Was ist Kaniko?

Kaniko wurde von Google entwickelt und ist heute das meistgenutzte Tool für Container-Image-Builds in Kubernetes. Kaniko läuft als Container (kein Daemon, keine Root-Rechte auf dem Node) und baut Images direkt aus einer Dockerfile.

Stärken von Kaniko:

  • Sehr einfaches Konzept: Kaniko-Container läuft im Cluster, baut aus Dockerfile
  • Hervorragende Kubernetes-Integration (als Job oder Init-Container)
  • Snapshot-basierter Layer-Bau (ähnlich docker build)
  • Unterstützt Docker Hub, ECR, GCR, GHCR, eigene Registries
  • Breite Adoption in GitLab CI, Tekton, Argo Workflows
  • Offizielles Google-Image (gcr.io/kaniko-project/executor)
  • Cache-Layer-Unterstützung via Registry-Cache (--cache=true)

Schwächen von Kaniko:

  • Nur für Kubernetes/CI-Umgebungen optimiert (kein lokaler Dev-Build-Flow)
  • Dockerfile muss im Executor-Container verfügbar sein (context via ConfigMap, Git, S3)
  • Einige Dockerfile-Features werden nicht unterstützt (z. B. bestimmte RUN-Konstrukte mit Mounts)
  • Kein Rootless im eigentlichen Sinne — läuft als root im Container, ohne Host-Privilegien

Technischer Vergleich

Merkmal Buildah Kaniko
Rootless ✓ (User Namespaces) Teilweise (kein Host-Root)
Kubernetes-nativ Möglich, komplexer ✓ (designed for K8s)
Dockerfile-Support ✓ ✓
Eigene Build-Skripte ✓ (buildah-API) Nur Dockerfile
Registry-Push ✓ (via Skopeo) ✓ (direkt)
Layer-Cache ✓ ✓ (Registry-Cache)
Lokale Nutzung ✓ Eingeschränkt
Multi-Stage Builds ✓ ✓
ARM-Support ✓ ✓
Maintainer Red Hat / Community Google / Community

Kaniko in GitLab CI

Das häufigste Einsatzszenario für Kaniko ist als Container in einer GitLab CI- oder GitHub Actions-Pipeline:

# .gitlab-ci.yml
build-image:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:v1.23.0-debug
    entrypoint: [""]
  script:
    - mkdir -p /kaniko/.docker
    - echo "{\"auths\":{\"registry.example.com\":{\"auth\":\"$(echo -n $CI_REGISTRY_USER:$CI_REGISTRY_PASSWORD | base64)\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor
        --context "${CI_PROJECT_DIR}"
        --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
        --destination "registry.example.com/myapp:${CI_COMMIT_SHORT_SHA}"
        --destination "registry.example.com/myapp:latest"
        --cache=true
        --cache-repo "registry.example.com/myapp/cache"
  only:
    - main

Der gesamte Build findet im Kaniko-Container statt — kein Docker-Socket, kein privilegierter Modus.

Buildah in einer Tekton-Pipeline

Für Kubernetes-native CI/CD mit Tekton ist Buildah die häufig gewählte Alternative:

# tekton-buildah-task.yaml
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: buildah-build-push
spec:
  params:
    - name: IMAGE
      description: "Ziel-Image (z.B. registry.example.com/myapp:tag)"
    - name: CONTEXT
      default: "."
  workspaces:
    - name: source
  steps:
    - name: build-and-push
      image: quay.io/buildah/stable:v1.35
      securityContext:
        privileged: false
        runAsUser: 1000
      script: |
        buildah bud \
          --tls-verify=false \
          --layers \
          -f Dockerfile \
          -t $(params.IMAGE) \
          $(params.CONTEXT)
        buildah push \
          --tls-verify=true \
          $(params.IMAGE) \
          docker://$(params.IMAGE)
      volumeMounts:
        - name: varlibcontainers
          mountPath: /var/lib/containers
  volumes:
    - name: varlibcontainers
      emptyDir: {}

Buildah benötigt hier kein privileged: true, wenn UserNamespaces im Cluster aktiviert sind — das ist der entscheidende Sicherheitsvorteil.

Multi-Stage Builds und Layer-Cache

Beide Tools unterstützen Docker-Multi-Stage-Builds. Der Cache-Mechanismus unterscheidet sich:

Kaniko Registry-Cache:

/kaniko/executor \
  --dockerfile=Dockerfile \
  --context=dir://workspace \
  --destination=registry.example.com/myapp:latest \
  --cache=true \
  --cache-repo=registry.example.com/myapp-cache \
  --cache-ttl=24h

Buildah Layer-Cache (lokal oder via Overlay-Storage):

buildah bud \
  --layers \
  --cache-from registry.example.com/myapp:latest \
  -t registry.example.com/myapp:new \
  .

Kanikos Registry-Cache ist praktischer für verteilte CI-Systeme, da der Cache in der Registry selbst liegt und von beliebig vielen Agents genutzt werden kann.

Wann Buildah, wann Kaniko?

Buildah ist die richtige Wahl wenn:

  • Rootless auf Kernel-Level (User Namespaces) Voraussetzung ist
  • Lokale Entwicklung und CI auf derselben Toolchain basieren sollen (Podman-Workflow)
  • Custom Build-Skripte jenseits von Dockerfile nötig sind
  • RHEL/CentOS/OpenShift-Umgebungen genutzt werden
  • Tekton als CI-System im Einsatz ist

Kaniko ist die richtige Wahl wenn:

  • Kubernetes-basierte CI/CD (GitLab CI, Argo Workflows, Tekton) im Einsatz ist
  • Schneller Einstieg ohne Kernel-Konfiguration gewünscht wird
  • Dockerfile als einziges Build-Format ausreicht
  • Cloud-Provider-Registries (GCR, ECR, GHCR) genutzt werden
  • Registry-Layer-Caching für schnelle Builds im Team wichtig ist

Alternativen: ko, img, Buildkit

  • ko (Google): Speziell für Go-Anwendungen — kein Dockerfile nötig, baut direkt aus Go-Source
  • BuildKit (docker buildx): Modernes Docker-Build-Backend mit rootless-Modus (erfordert jedoch often noch Daemon)
  • img (Jessie Frazelle): Rootless Builder auf BuildKit-Basis — weniger aktiv maintained
  • Podman + Buildah: Vollständige rootless Container-Toolchain für lokale Entwicklung

Fazit

Buildah und Kaniko sind beide solide, sicherheitsorientierte Alternativen zu Docker-in-Docker — die Wahl hängt vom Ökosystem ab. Wer auf Kubernetes und standardisierte CI/CD-Systeme setzt, greift 2026 in den meisten Fällen zu Kaniko: es ist einfacher zu integrieren, breit adoptiert und läuft ohne Kernel-Anforderungen. Wer hingegen in der Red-Hat-/Podman-Welt zu Hause ist oder maximale Rootless-Sicherheit auf Kernel-Ebene benötigt, macht mit Buildah die bessere Wahl.

In beiden Fällen gilt: Docker-Socket-Mounting oder DinD mit privileged: true sind in sicherheitsbewussten Kubernetes-Umgebungen 2026 keine akzeptable Option mehr.

Weiterführende Artikel

Verwandte Technologien im Techradar