kaniko

Status

Version: 1.1.3 | Tests: Passing

Usage

devcontainer.json

{
    "features": {
        "ghcr.io/infrashift/trusted-devcontainer-features/kaniko:latest": {
            "target_version": "1.28.6"
        }
    }
}

Options

Option	Type	Default	Description
target_version	string	1.28.6	Select a supported kaniko version
target_executor_checksum	string	""	SHA256 of the OCI layer holding kaniko/executor
target_warmer_checksum	string	""	SHA256 of the OCI layer holding kaniko/warmer

Dependencies

None — this feature is independent and has no dependencies.

How It Works

This feature installs the kaniko executor and cache warmer as kaniko-executor and kaniko-warmer. Upstream is the osscontainertools/kaniko community fork that succeeded the archived GoogleContainerTools/kaniko, and it is the same upstream the infrashift Guix channel packages.

kaniko publishes no release binaries — container images are its only distribution channel. Each binary happens to occupy its own dedicated image layer, so the Ansible role downloads exactly one blob per binary straight from the registry rather than unpacking an image, and needs no container runtime to do it. Because an OCI blob is addressed by the sha256 of its own bytes, the pinned digest serves as both the download URL and the checksum that verifies it, which keeps the feature inside ADR-006 with no new verification machinery. Digests are pinned per version and per architecture; an unpinned combination is a named failure rather than a silent skip of verification.

Both binaries install under a version-scoped prefix, ~/.local/share/kaniko/<version>/, with symlinks into ~/.local/bin. The prefix is not decoration: kaniko-warmer has no version subcommand, no --version flag and nothing in its help output, so the path is the only place the installed version is legible. The role verifies the executor by running kaniko-executor version and matching the requested version, and verifies the warmer by confirming its symlink resolves to an executable inside that prefix.

One caveat matters more than the rest: kaniko is not a normal CLI. The executor unpacks the base image into its own / and sweeps the root filesystem, so running it unwrapped inside a dev container will try to modify the container’s own root. This feature installs the binaries; making that safe requires running the executor chrooted into a synthetic root, which needs only CAP_SYS_CHROOT. See the feature’s NOTES.md for the details and a pointer to a working implementation.