konairius/homelab
10
0
Fork 0
Code Issues 8 Pull Requests 5 Packages Projects Releases 1 Wiki Activity

kaniko is archived upstream — all CI image builds depend on an abandoned tool #552

New Issue
Closed
opened 2026-08-21 20:52:25 +00:00 by claude-bot · 7 comments
claude-bot commented 2026-08-21 20:52:25 +00:00
Member
Copy Link
Copy Source

Surfaced while bumping pins for #426 (see #551).

State

GoogleContainerTools/kaniko   archived 2025-06-03
last release                  v1.24.0, 2025-05-21
our pin after #551            v1.24.0-debug  (the final release)

Every container image this repo builds goes through kaniko: 9 build steps in .woodpecker/build-ci-images.yml plus the image rebuild in .woodpecker/ci-claude-refresh.yml.

The version is now permanently frozen. No further security fixes will be published for the executor image or its dependency tree — Go stdlib, containerd, go-git, the AWS SDK, the auth binaries in the -debug variant. The update audit will stop reporting kaniko as behind, which is misleading: it is not current, it is terminal.

Why it is not urgent but should not be ignored

kaniko runs inside CI on already-trusted inputs, so the exposure is narrower than a network-facing service. Nothing is broken today and builds work.

The cost is that it only gets worse: dependency CVEs accumulate with no upstream to fix them, and a future Kubernetes or containerd change that kaniko cannot handle would break all image builds at once, with no upgrade path available.

Replacement options

Requirement worth stating up front: whatever replaces it must build without a privileged container or a Docker socket, matching how kaniko is used now.

  1. BuildKit rootless (moby/buildkit:*-rootless) — the most direct successor, actively developed, supports rootless builds in Kubernetes. Needs a check that the Woodpecker Kubernetes backend can give it the required securityContext without violating the no-privileged rule.
  2. Buildah — rootless-capable, well maintained, no daemon. Fully supports Dockerfile syntax.
  3. Woodpecker's official docker-buildx plugin — best integrated with the CI in use, but typically wants a Docker socket, which would not be acceptable here.

Option 1 or 2. Neither is a drop-in for the kaniko flags currently used (--context, --dockerfile, --destination, the /kaniko/.docker/config.json auth setup), so this is a real migration of ~10 build steps, not a find-and-replace.

Refs #426, #551

Surfaced while bumping pins for #426 (see #551). ## State ``` GoogleContainerTools/kaniko archived 2025-06-03 last release v1.24.0, 2025-05-21 our pin after #551 v1.24.0-debug (the final release) ``` Every container image this repo builds goes through kaniko: 9 build steps in `.woodpecker/build-ci-images.yml` plus the image rebuild in `.woodpecker/ci-claude-refresh.yml`. The version is now permanently frozen. No further security fixes will be published for the executor image or its dependency tree — Go stdlib, containerd, go-git, the AWS SDK, the auth binaries in the `-debug` variant. The update audit will stop reporting kaniko as behind, which is misleading: it is not current, it is terminal. ## Why it is not urgent but should not be ignored kaniko runs inside CI on already-trusted inputs, so the exposure is narrower than a network-facing service. Nothing is broken today and builds work. The cost is that it only gets worse: dependency CVEs accumulate with no upstream to fix them, and a future Kubernetes or containerd change that kaniko cannot handle would break all image builds at once, with no upgrade path available. ## Replacement options Requirement worth stating up front: whatever replaces it must build **without a privileged container or a Docker socket**, matching how kaniko is used now. 1. **BuildKit rootless** (`moby/buildkit:*-rootless`) — the most direct successor, actively developed, supports rootless builds in Kubernetes. Needs a check that the Woodpecker Kubernetes backend can give it the required `securityContext` without violating the no-privileged rule. 2. **Buildah** — rootless-capable, well maintained, no daemon. Fully supports Dockerfile syntax. 3. **Woodpecker's official docker-buildx plugin** — best integrated with the CI in use, but typically wants a Docker socket, which would not be acceptable here. Option 1 or 2. Neither is a drop-in for the kaniko flags currently used (`--context`, `--dockerfile`, `--destination`, the `/kaniko/.docker/config.json` auth setup), so this is a real migration of ~10 build steps, not a find-and-replace. Refs #426, #551
claude-bot commented 2026-08-21 20:52:55 +00:00
Author
Member
Copy Link
Copy Source

Worth noting the variant, since it widens the frozen surface.

All 10 steps use -debug, which is the largest image — busybox shell plus the auth binaries — rather than executor:v1.24.0 or -slim. That is not gratuitous: the steps run shell to construct registry auth and a tag.

mkdir -p /kaniko/.docker
AUTH=$(printf '%s:%s' "$GITEA_USER" "$GITEA_TOKEN" | base64 | tr -d '\n')
printf '{"auths":{"gitea.renner.uno":{"auth":"%s"}}}' "$AUTH" > /kaniko/.docker/config.json
TAG=$(date +%Y-%m-%d)

The plain executor image has no shell, so -debug is required by how the steps are written today.

Both shell uses are avoidable:

  • auth — mount a pre-built config.json as a secret volume instead of assembling it inline. Also stops the token passing through a shell variable and a base64 invocation in the step log.
  • tag — Woodpecker exposes pipeline metadata (CI_PIPELINE_*) that can supply a tag without date.

Removing them means the build step needs no shell at all, which shrinks the frozen kaniko surface immediately and makes the eventual migration easier — BuildKit and Buildah both prefer mounted credentials over a shell-assembled config. Worth doing as the first step of this issue rather than after choosing a replacement, since it is independent of which one wins.

Worth noting the variant, since it widens the frozen surface. All 10 steps use `-debug`, which is the largest image — busybox shell plus the auth binaries — rather than `executor:v1.24.0` or `-slim`. That is not gratuitous: the steps run shell to construct registry auth and a tag. ``` mkdir -p /kaniko/.docker AUTH=$(printf '%s:%s' "$GITEA_USER" "$GITEA_TOKEN" | base64 | tr -d '\n') printf '{"auths":{"gitea.renner.uno":{"auth":"%s"}}}' "$AUTH" > /kaniko/.docker/config.json TAG=$(date +%Y-%m-%d) ``` The plain executor image has no shell, so `-debug` is required by how the steps are written today. Both shell uses are avoidable: - **auth** — mount a pre-built `config.json` as a secret volume instead of assembling it inline. Also stops the token passing through a shell variable and a `base64` invocation in the step log. - **tag** — Woodpecker exposes pipeline metadata (`CI_PIPELINE_*`) that can supply a tag without `date`. Removing them means the build step needs no shell at all, which shrinks the frozen kaniko surface immediately and makes the eventual migration easier — BuildKit and Buildah both prefer mounted credentials over a shell-assembled config. Worth doing as the first step of this issue rather than after choosing a replacement, since it is independent of which one wins.
claude-bot commented 2026-08-21 20:55:31 +00:00
Author
Member
Copy Link
Copy Source

Adding a hard constraint from the owner: debug image variants are not to run in the production cluster.

That rules out the obvious stopgap. Bumping to executor:v1.24.0-debug would have picked up the go-git CVE-2025-21613 fix and containerd 1.7.18 -> 1.7.27, but it pins a new debug image, so it has been dropped from #551 (which is now alpine-only).

Current state is the worst corner: the cluster runs v1.23.2-debug — a debug variant and missing that CVE fix — and there is no version bump that fixes both, because the only newer release is also only useful in its debug form given how the steps are written.

This makes the migration the fix, and constrains it

Requirements for the replacement, in order:

  1. No debug/shell-bearing image in the production cluster.
  2. No privileged container and no Docker socket.
  3. Builds the existing Containerfiles unchanged.

Constraint worth recording: Woodpecker steps that use commands: need a shell in the image by definition. Getting to a shell-less build step therefore needs either entrypoint override — reported broken on the Kubernetes backend, which is the backend in use — or a plugin-style image that takes settings: as PLUGIN_* env vars and needs no shell.

The plugin route fits requirement 1 naturally: a purpose-built BuildKit or Buildah plugin image runs its own entrypoint with no shell, and credentials arrive as settings rather than being assembled by printf into /kaniko/.docker/config.json.

The auth and tag cleanup noted in my previous comment is still the right first move and is unaffected by which replacement wins.

Adding a hard constraint from the owner: **debug image variants are not to run in the production cluster.** That rules out the obvious stopgap. Bumping to `executor:v1.24.0-debug` would have picked up the go-git CVE-2025-21613 fix and containerd 1.7.18 -> 1.7.27, but it pins a new debug image, so it has been dropped from #551 (which is now alpine-only). Current state is the worst corner: the cluster runs **v1.23.2-debug** — a debug variant *and* missing that CVE fix — and there is no version bump that fixes both, because the only newer release is also only useful in its debug form given how the steps are written. ## This makes the migration the fix, and constrains it Requirements for the replacement, in order: 1. **No debug/shell-bearing image in the production cluster.** 2. No privileged container and no Docker socket. 3. Builds the existing Containerfiles unchanged. Constraint worth recording: Woodpecker steps that use `commands:` need a shell in the image by definition. Getting to a shell-less build step therefore needs either `entrypoint` override — [reported broken on the Kubernetes backend](https://github.com/woodpecker-ci/woodpecker/issues/3477), which is the backend in use — or a plugin-style image that takes `settings:` as `PLUGIN_*` env vars and needs no shell. The plugin route fits requirement 1 naturally: a purpose-built BuildKit or Buildah plugin image runs its own entrypoint with no shell, and credentials arrive as settings rather than being assembled by `printf` into `/kaniko/.docker/config.json`. The auth and tag cleanup noted in my previous comment is still the right first move and is unaffected by which replacement wins.
claude-bot commented 2026-08-21 21:11:22 +00:00
Author
Member
Copy Link
Copy Source

Evaluated BuildKit rootless. Result: no in-cluster builder runs without some privilege relaxation. That is the real constraint, and it should be decided before any migration work starts.

BuildKit rootless

Does not need privileged: true, but the documented Kubernetes securityContext is:

seccompProfile: unconfined
procMount: Unmasked
allowPrivilegeEscalation: true
capabilities: CHOWN, DAC_OVERRIDE, FOWNER, FSETID, SETGID, SETUID, SETFCAP
runAsUser/runAsGroup: 1000

seccompProfile: unconfined plus procMount: Unmasked is not obviously a smaller concession than privileged — it is a different one. Worth a deliberate call rather than treating "not privileged" as sufficient.

Buildah plugin

Two modes, and the docs are inconsistent about which is default:

  • fuse-overlayfs needs /dev/fuse. Kubernetes does not allow arbitrary device mounts without either privileged: true or a device plugin, so this needs one or the other.
  • VFS fallback needs no extra privileges, but copies the whole layer stack on every operation — upstream warns about "many gigabytes of layer data during runtime". Given the OSDs are at 81-87% wear, deliberately adopting a write-amplifying build path is the wrong direction.

Also flagged as early-stage upstream.

The option not yet considered

Build images outside the cluster entirely. That sidesteps the whole class — no privilege relaxation, no write amplification on the Ceph OSDs, no dead-tool dependency. Costs a build host or an external runner, and moves where registry credentials live.

Where this leaves it

Four choices, none free:

  1. BuildKit rootless — unconfined seccomp + unmasked procMount
  2. Buildah + fuse-overlayfs — privileged or a device plugin
  3. Buildah + VFS — heavy layer writes onto worn drives
  4. Build off-cluster — new infrastructure, credentials move

This is a decision about which concession is acceptable, not a technical blocker to work around. Not proceeding until that is settled.

Evaluated BuildKit rootless. Result: **no in-cluster builder runs without some privilege relaxation.** That is the real constraint, and it should be decided before any migration work starts. ## BuildKit rootless Does not need `privileged: true`, but the documented Kubernetes securityContext is: ``` seccompProfile: unconfined procMount: Unmasked allowPrivilegeEscalation: true capabilities: CHOWN, DAC_OVERRIDE, FOWNER, FSETID, SETGID, SETUID, SETFCAP runAsUser/runAsGroup: 1000 ``` `seccompProfile: unconfined` plus `procMount: Unmasked` is not obviously a smaller concession than privileged — it is a different one. Worth a deliberate call rather than treating "not privileged" as sufficient. ## Buildah plugin Two modes, and the docs are inconsistent about which is default: - **fuse-overlayfs** needs `/dev/fuse`. Kubernetes does not allow arbitrary device mounts without either `privileged: true` or a device plugin, so this needs one or the other. - **VFS fallback** needs no extra privileges, but copies the whole layer stack on every operation — upstream warns about "many gigabytes of layer data during runtime". Given the OSDs are at 81-87% wear, deliberately adopting a write-amplifying build path is the wrong direction. Also flagged as early-stage upstream. ## The option not yet considered Build images **outside the cluster** entirely. That sidesteps the whole class — no privilege relaxation, no write amplification on the Ceph OSDs, no dead-tool dependency. Costs a build host or an external runner, and moves where registry credentials live. ## Where this leaves it Four choices, none free: 1. BuildKit rootless — unconfined seccomp + unmasked procMount 2. Buildah + fuse-overlayfs — privileged or a device plugin 3. Buildah + VFS — heavy layer writes onto worn drives 4. Build off-cluster — new infrastructure, credentials move This is a decision about which concession is acceptable, not a technical blocker to work around. Not proceeding until that is settled.
claude-bot commented 2026-08-21 21:14:01 +00:00
Author
Member
Copy Link
Copy Source

Retracting the previous comment's framing. I applied general-purpose "build arbitrary images in Kubernetes" requirements to builds that do not need them.

What is actually built here:

FROM alpine@sha256:...
RUN apk add --no-cache <packages>
RUN curl -sfL -o /usr/local/bin/<tool> ... && sha256sum -c - && chmod +x

Single stage, no compilation, no untrusted input, pinned base by digest. Unpack a rootfs, run a few shell commands in it, tar the result, push.

That needs no namespace isolation. The seccomp-unconfined / procMount-Unmasked / capability list I quoted is what BuildKit wants to run a daemon with full isolation — irrelevant here. It is also exactly why kaniko ran unprivileged: it executes RUN directly in its own container filesystem, which is fine for builds of this shape.

buildah with --isolation chroot and vfs storage covers it: no privileged, no /dev/fuse, no seccomp or apparmor changes, no device plugin.

The VFS disk-usage objection also does not apply at this scale. Upstream's "many gigabytes during runtime" warning is about deep multi-stage builds; these are a handful of layers on ~1.3G images, and each step only fires when its own source path changes.

Revised position — the earlier four-way decision was manufactured:

  • Use a buildah-based plugin with chroot isolation and vfs.
  • No privilege concession required.
  • Remaining real work is the step conversion: registry auth and tags become plugin settings: instead of shell-assembled config.json and date.
Retracting the previous comment's framing. I applied general-purpose "build arbitrary images in Kubernetes" requirements to builds that do not need them. What is actually built here: ``` FROM alpine@sha256:... RUN apk add --no-cache <packages> RUN curl -sfL -o /usr/local/bin/<tool> ... && sha256sum -c - && chmod +x ``` Single stage, no compilation, no untrusted input, pinned base by digest. Unpack a rootfs, run a few shell commands in it, tar the result, push. That needs no namespace isolation. The seccomp-unconfined / procMount-Unmasked / capability list I quoted is what BuildKit wants to run a **daemon** with full isolation — irrelevant here. It is also exactly why kaniko ran unprivileged: it executes RUN directly in its own container filesystem, which is fine for builds of this shape. **buildah with `--isolation chroot` and vfs storage covers it**: no `privileged`, no `/dev/fuse`, no seccomp or apparmor changes, no device plugin. The VFS disk-usage objection also does not apply at this scale. Upstream's "many gigabytes during runtime" warning is about deep multi-stage builds; these are a handful of layers on ~1.3G images, and each step only fires when its own source path changes. Revised position — the earlier four-way decision was manufactured: - Use a buildah-based plugin with chroot isolation and vfs. - No privilege concession required. - Remaining real work is the step conversion: registry auth and tags become plugin `settings:` instead of shell-assembled `config.json` and `date`.
claude-bot commented 2026-08-22 06:57:15 +00:00
Author
Member
Copy Link
Copy Source

Retracting my previous retraction. I tested it; the earlier analysis was right and the "no privilege concession required" claim was wrong.

Test

docker run --user 0 -e BUILDAH_ISOLATION=chroot -e STORAGE_DRIVER=vfs \
  quay.io/buildah/stable buildah bud -f Containerfile -t test .
-> Error during unshare(CLONE_NEWUSER): Operation not permitted

+ --security-opt seccomp=unconfined
-> While applying layer: remount /, flags: 0x44000: permission denied

+ --cap-add SYS_ADMIN
-> same failure

Built against the real ci/images/alpine-jq/Containerfile. Neither the isolation mode nor the storage driver was the gate — the image already ships BUILDAH_ISOLATION=chroot. buildah needs to apply layers via mount syscalls, and remount / is refused without --privileged.

What this means

kaniko's unprivileged operation is not incidental, it is the whole reason it exists: it applies layers directly into its own container filesystem and executes RUN there, using no mount syscalls. That is unusual, and it is why it was the standard answer for building images in Kubernetes.

Every maintained replacement does real container work and therefore needs real privileges:

  • buildah — privileged (demonstrated above)
  • BuildKit rootless — seccomp unconfined, procMount Unmasked, allowPrivilegeEscalation, 7 capabilities
  • Buildah + fuse-overlayfs — /dev/fuse, so privileged or a device plugin

The observation that these Containerfiles are trivial (FROM alpine@sha256, apk add, curl | sha256sum -c) is true but does not help: the privilege is needed to unpack and commit layers, not to run the build steps.

Position

The four-way choice in my earlier comment stands, with option 4 (build off-cluster) looking better than it did — it is the only one that needs no privilege concession, and for builds this simple a plain runner with podman or docker is sufficient.

kaniko being archived while remaining the only unprivileged in-cluster builder is the actual problem here, and it does not have a clean answer.

Retracting my previous retraction. I tested it; the earlier analysis was right and the "no privilege concession required" claim was wrong. ## Test ``` docker run --user 0 -e BUILDAH_ISOLATION=chroot -e STORAGE_DRIVER=vfs \ quay.io/buildah/stable buildah bud -f Containerfile -t test . -> Error during unshare(CLONE_NEWUSER): Operation not permitted + --security-opt seccomp=unconfined -> While applying layer: remount /, flags: 0x44000: permission denied + --cap-add SYS_ADMIN -> same failure ``` Built against the real `ci/images/alpine-jq/Containerfile`. Neither the isolation mode nor the storage driver was the gate — the image already ships `BUILDAH_ISOLATION=chroot`. buildah needs to apply layers via mount syscalls, and `remount /` is refused without `--privileged`. ## What this means kaniko's unprivileged operation is not incidental, it is the whole reason it exists: it applies layers directly into its own container filesystem and executes RUN there, using no mount syscalls. That is unusual, and it is why it was the standard answer for building images in Kubernetes. Every maintained replacement does real container work and therefore needs real privileges: - **buildah** — privileged (demonstrated above) - **BuildKit rootless** — seccomp unconfined, procMount Unmasked, allowPrivilegeEscalation, 7 capabilities - **Buildah + fuse-overlayfs** — /dev/fuse, so privileged or a device plugin The observation that these Containerfiles are trivial (`FROM alpine@sha256`, `apk add`, `curl | sha256sum -c`) is true but does not help: the privilege is needed to unpack and commit layers, not to run the build steps. ## Position The four-way choice in my earlier comment stands, with option 4 (build off-cluster) looking better than it did — it is the only one that needs no privilege concession, and for builds this simple a plain runner with podman or docker is sufficient. kaniko being archived while remaining the only unprivileged in-cluster builder is the actual problem here, and it does not have a clean answer.
claude-bot commented 2026-08-27 10:38:27 +00:00
Author
Member
Copy Link
Copy Source

Recherche-Stand, alles aus Doku und Live-Zustand belegt. Der praktische Test hängt noch (unten).

Zwei Zahlen im Issue stimmen nicht, beide im Baum nachprüfbar:

  • Der Pin ist überall v1.23.2-debug, nicht v1.24.0-debug. #551 hat nur Alpine in deploy-infrastructure.yml gebumpt, kaniko nicht angefasst.
  • Es sind acht Build-Steps in build-ci-images.yml plus einer in ci-claude-refresh.yml — neun kaniko-Aufrufe, nicht zehn.

Der Rest der Lagebeschreibung stimmt: archiviert am 2025-06-03, Hinweis wörtlich „🧊 This project is archived and no longer developed or maintained. 🧊", kein empfohlener Nachfolger.

Die Randbedingung ist enger als im Issue angenommen. Der Woodpecker-Agent läuft mit WOODPECKER_BACKEND=kubernetes in woodpecker-ci. Die Namespace-PSA steht auf pod-security.kubernetes.io/enforce: privileged — die Einschränkung „kein privilegierter Container" ist hier also Policy, nicht Admission. Woodpecker erlaubt pro Step einen securityContext mit runAsUser, capabilities, seccompProfile, apparmorProfile, privileged — aber kein procMount.

Damit sortieren sich die beiden Kandidaten anders als im Issue:

  • Rootless BuildKit — der dokumentierte Kubernetes-Weg ist --oci-worker-no-process-sandbox, und upstream rät selbst davon ab: es „allows ExecOp containers to kill (and potentially ptrace …) an arbitrary process in the BuildKit daemon container". Der saubere Weg wäre procMount: Unmasked zusammen mit hostUsers: false — genau das Feld, das Woodpecker nicht durchreicht. Das ist kein „muss man prüfen", das ist eine Sackgasse, solange der Backend das nicht kann.
  • Buildah — der overlay-Treiber will /dev/fuse, das ein unprivilegierter Pod nicht bekommt. Bleibt --storage-driver vfs --isolation chroot, das ohne zusätzliche Capabilities auskommt. Preis: vfs kopiert jede Layer statt sie zu stapeln, also langsamer und plattenhungriger. Das ist hier nicht egal — wp-agent-memory-4gib hält fest, dass vier parallele kaniko-Builds die Agents schon einmal ins OOM getrieben haben.

Also: Buildah mit vfs+chroot ist der einzige Kandidat, der die Regel ohne Auslegung einhält. Ob er trägt, ist eine Messung, keine Meinung.

Stand des Tests. .woodpecker/buildah-probe.yml liegt auf Branch kaniko-replacement: baut alpine-jq (kleinster Kontext, ein FROM, ein RUN) mit buildah, pusht auf einen :buildah-probe-Tag, damit nichts an :latest hängt, und benutzt das Ergebnis danach als Step-Image — ein Build, der durchläuft aber ein nicht startbares Image erzeugt, sähe sonst wie Erfolg aus. Manual-only und ohne path:-Trigger, damit die Messung nicht die acht kaniko-Images neu baut.

woodpecker-cli lint sagt gültig, aber woodpecker-cli pipeline create bricht dreimal mit EOF ab und hinterlässt keinen Server-Log. Ich habe deshalb aufgehört zu raten, statt weiter gegen die produktive CI zu stochern. Nächster Schritt wäre ein Auslösen über die UI, oder — falls es doch am when liegt — ein Lauf ohne die evaluate-Zeile, um genau das zu isolieren.

Recherche-Stand, alles aus Doku und Live-Zustand belegt. Der praktische Test hängt noch (unten). **Zwei Zahlen im Issue stimmen nicht**, beide im Baum nachprüfbar: - Der Pin ist überall `v1.23.2-debug`, nicht `v1.24.0-debug`. #551 hat nur Alpine in `deploy-infrastructure.yml` gebumpt, kaniko nicht angefasst. - Es sind **acht** Build-Steps in `build-ci-images.yml` plus einer in `ci-claude-refresh.yml` — neun kaniko-Aufrufe, nicht zehn. Der Rest der Lagebeschreibung stimmt: archiviert am 2025-06-03, Hinweis wörtlich „🧊 This project is archived and no longer developed or maintained. 🧊", kein empfohlener Nachfolger. **Die Randbedingung ist enger als im Issue angenommen.** Der Woodpecker-Agent läuft mit `WOODPECKER_BACKEND=kubernetes` in `woodpecker-ci`. Die Namespace-PSA steht auf `pod-security.kubernetes.io/enforce: privileged` — die Einschränkung „kein privilegierter Container" ist hier also Policy, nicht Admission. Woodpecker erlaubt pro Step einen `securityContext` mit `runAsUser`, `capabilities`, `seccompProfile`, `apparmorProfile`, `privileged` — **aber kein `procMount`**. Damit sortieren sich die beiden Kandidaten anders als im Issue: - **Rootless BuildKit** — der dokumentierte Kubernetes-Weg ist `--oci-worker-no-process-sandbox`, und upstream rät selbst davon ab: es „allows ExecOp containers to kill (and potentially ptrace …) an arbitrary process in the BuildKit daemon container". Der saubere Weg wäre `procMount: Unmasked` zusammen mit `hostUsers: false` — genau das Feld, das Woodpecker nicht durchreicht. Das ist kein „muss man prüfen", das ist eine Sackgasse, solange der Backend das nicht kann. - **Buildah** — der overlay-Treiber will `/dev/fuse`, das ein unprivilegierter Pod nicht bekommt. Bleibt `--storage-driver vfs --isolation chroot`, das ohne zusätzliche Capabilities auskommt. Preis: vfs kopiert jede Layer statt sie zu stapeln, also langsamer und plattenhungriger. Das ist hier nicht egal — [[wp-agent-memory-4gib]] hält fest, dass vier parallele kaniko-Builds die Agents schon einmal ins OOM getrieben haben. Also: **Buildah mit vfs+chroot ist der einzige Kandidat, der die Regel ohne Auslegung einhält.** Ob er trägt, ist eine Messung, keine Meinung. **Stand des Tests.** `.woodpecker/buildah-probe.yml` liegt auf Branch `kaniko-replacement`: baut `alpine-jq` (kleinster Kontext, ein FROM, ein RUN) mit buildah, pusht auf einen `:buildah-probe`-Tag, damit nichts an `:latest` hängt, und benutzt das Ergebnis danach als Step-Image — ein Build, der durchläuft aber ein nicht startbares Image erzeugt, sähe sonst wie Erfolg aus. Manual-only und ohne `path:`-Trigger, damit die Messung nicht die acht kaniko-Images neu baut. `woodpecker-cli lint` sagt gültig, aber `woodpecker-cli pipeline create` bricht dreimal mit `EOF` ab und hinterlässt keinen Server-Log. Ich habe deshalb aufgehört zu raten, statt weiter gegen die produktive CI zu stochern. Nächster Schritt wäre ein Auslösen über die UI, oder — falls es doch am `when` liegt — ein Lauf ohne die `evaluate`-Zeile, um genau das zu isolieren.
claude-bot commented 2026-08-27 10:55:11 +00:00
Author
Member
Copy Link
Copy Source

Korrektur zu meinem vorigen Kommentar — der war die Antwort auf die falsche Frage.

kaniko ist nicht eingefroren. Google hat das Repo am 2025-06-03 archiviert, aber die ursprünglichen Autoren haben es zu chainguard-dev/kaniko geforkt und weiter released. Aktueller Stand: v1.25.18, also achtzehn Releases über der v1.24.0 hinaus, bei der das Google-Repo endete. Der Satz im Issue — „The version is now permanently frozen. No further security fixes will be published" — trifft nicht zu. Upstream ist umgezogen, nicht gestorben.

Damit ist die ganze Ersatz-Analyse gegenstandslos: kein buildah, kein BuildKit, kein procMount-Problem, keine neun umgeschriebenen Steps. Es ist ein Image-Tausch.

Die Fork veröffentlicht selbst keine Binaries. gitlab-ci-utils baut aus ihr Images für amd64 und arm64 mit Versions-Tags: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug.

Gezogen und ausgeführt statt nur nachgelesen:

-rwxr-xr-x  53039266  /kaniko/executor
Kaniko version :  v1.25.18
/bin/sh -> /busybox/sh
printf  /busybox/base64  /busybox/tr  /busybox/mkdir  /busybox/date

Gleicher Pfad, gleiche Flags, alle Utilities der Auth- und Tag-Zeilen vorhanden, anonymer Pull möglich.

#664 zieht alpine-jq als ersten Step um. Weil eine Änderung an build-ci-images.yml ohnehin alle Steps neu baut, zeigt ein Lauf den neuen Executor neben sieben unveränderten kaniko-Builds. Die restlichen sieben und ci-claude-refresh.yml folgen, wenn das grün ist.

Zu meinem Irrweg: ich habe „archived upstream" als Wartungs- und Sicherheitsproblem gelesen und bin sofort zur Werkzeugauswahl gesprungen, statt die naheliegendste Frage zu stellen — hat das jemand übernommen. Die Buildah-Probe habe ich wieder entfernt; die Analyse oben bleibt als Notiz stehen, falls die Fork eines Tages doch aufgibt. Dann ist buildah mit vfs+chroot der einzige Kandidat, der die Kein-Privileg-Regel ohne Auslegung einhält, und procMount bleibt der Grund, warum rootless BuildKit hier nicht geht.

Korrektur zu meinem vorigen Kommentar — der war die Antwort auf die falsche Frage. **kaniko ist nicht eingefroren.** Google hat das Repo am 2025-06-03 archiviert, aber die ursprünglichen Autoren haben es zu `chainguard-dev/kaniko` geforkt und weiter released. Aktueller Stand: **v1.25.18**, also achtzehn Releases über der v1.24.0 hinaus, bei der das Google-Repo endete. Der Satz im Issue — „The version is now permanently frozen. No further security fixes will be published" — trifft nicht zu. Upstream ist umgezogen, nicht gestorben. Damit ist die ganze Ersatz-Analyse gegenstandslos: kein buildah, kein BuildKit, kein `procMount`-Problem, keine neun umgeschriebenen Steps. Es ist ein Image-Tausch. Die Fork veröffentlicht selbst keine Binaries. `gitlab-ci-utils` baut aus ihr Images für amd64 und arm64 mit Versions-Tags: `registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug`. Gezogen und ausgeführt statt nur nachgelesen: ``` -rwxr-xr-x 53039266 /kaniko/executor Kaniko version : v1.25.18 /bin/sh -> /busybox/sh printf /busybox/base64 /busybox/tr /busybox/mkdir /busybox/date ``` Gleicher Pfad, gleiche Flags, alle Utilities der Auth- und Tag-Zeilen vorhanden, anonymer Pull möglich. #664 zieht `alpine-jq` als ersten Step um. Weil eine Änderung an `build-ci-images.yml` ohnehin alle Steps neu baut, zeigt ein Lauf den neuen Executor neben sieben unveränderten kaniko-Builds. Die restlichen sieben und `ci-claude-refresh.yml` folgen, wenn das grün ist. Zu meinem Irrweg: ich habe „archived upstream" als Wartungs- und Sicherheitsproblem gelesen und bin sofort zur Werkzeugauswahl gesprungen, statt die naheliegendste Frage zu stellen — hat das jemand übernommen. Die Buildah-Probe habe ich wieder entfernt; die Analyse oben bleibt als Notiz stehen, falls die Fork eines Tages doch aufgibt. Dann ist buildah mit `vfs`+`chroot` der einzige Kandidat, der die Kein-Privileg-Regel ohne Auslegung einhält, und `procMount` bleibt der Grund, warum rootless BuildKit hier nicht geht.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
apollo
Hermes expert: Immich, Audiobookshelf, Libation, Navidrome, Music Assistant
 atlas
Hermes expert: Talos, Flux, network, Authentik, Matrix, monitoring
 clio
Hermes expert: Paperless, wiki, ical-proxy, TRMNL, websites
 daedalus
Hermes expert: Gitea, Woodpecker, Renovate, review-bot, Hermes
 hestia
Hermes expert: Home Assistant, IoT, MQTT, ESPHome, voice
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
alert-monitor-bot claude-bot (Claude Bot) flux hermes-bot issue-fix-bot k.renner renovate-bot review-bot (Review Bot) security-bot update-audit-bot
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: konairius/homelab#552