Build and push a container image from a Dockerfile in a CI pipeline or Kubernetes Job without a Docker daemon, using kaniko, with registry authentication and remote layer caching.

Documented steps

1. IMPORTANT: GoogleContainerTools/kaniko was archived by Google in June 2025 (README banner: 'This project is archived and no longer developed or maintained'). For new/production use, prefer the maintained fork at https://github.com/chainguard-dev/kaniko, which continues security patches; no major feature work is planned there either. Old gcr.io/kaniko-project/executor and gcr.io/kaniko-project/warmer images are unmaintained and no longer updated per the fork README — build your own from chainguard-dev/kaniko or use Chainguard's commercial images at https://images.chainguard.dev/directory/image/kaniko.
2. kaniko MUST be run as the official executor image (gcr.io/kaniko-project/executor, or the maintained fork's image) — do not copy the kaniko binary into another image (e.g. a Jenkins agent); this is explicitly unsupported ('Known Issues' in the README at github.com/GoogleContainerTools/kaniko).
3. Basic Kubernetes Pod spec: image gcr.io/kaniko-project/executor:latest, args: ['--dockerfile=<path within context>', '--context=gs://<bucket>/<path>.tar.gz (or dir://, tar://, s3://, git://)', '--destination=<registry>/<repo>:<tag>']. Same pattern for docker run or a CI build step (e.g. Google Cloud Build: use the image as a build step with the same three args).
4. Registry auth via a Docker config.json mounted at /kaniko/.docker/config.json (mount a Secret there, or set the DOCKER_CONFIG env var to point elsewhere). For GCR: set GOOGLE_APPLICATION_CREDENTIALS to a mounted service-account JSON key, or use GKE Workload Identity. For Amazon ECR: the amazon-ecr-credential-helper is built into the executor image — use instance/pod role permissions (set AWS_SDK_LOAD_CONFIG=true) or mount ~/.aws/credentials at /root/.aws/. For Docker Hub: base64-encode 'USER:PASSWORD' into config.json under auths['https://index.docker.io/v1/'].auth. For ACR: use the built-in 'acr-env' credential helper via credHelpers in config.json for the specific *.azurecr.io registry (avoid credsStore since it applies to all registries), with AZURE_CLIENT_ID/AZURE_CLIENT_SECRET/AZURE_TENANT_ID env or managed identity.
5. Enable remote layer caching with --cache=true. Optionally set --cache-repo=<repo> to control where cached layers are stored; if omitted, kaniko infers <destination>/cache. Control which layers are cached with --cache-copy-layers and --cache-run-layers. --cache-ttl duration controls cache expiry (default two weeks). For base-image caching, pre-warm a local dir with the warmer image (gcr.io/kaniko-project/warmer:latest --cache-dir=/workspace/cache --image=<img>) and mount that dir into the executor via --cache-dir (default /cache).
6. --dockerfile flag: path to the Dockerfile to build (default 'Dockerfile'). --context: build context location with a scheme prefix (dir://, tar://, gs://, s3://, git://, https:// for Azure Blob, or bare path = local dir). --destination: full image ref including tag/registry to push to; can be repeated for multiple tags.
7. kaniko images are cosign-signed for versions >= 1.5.2: cosign verify -key ./cosign.pub gcr.io/kaniko-project/executor:latest, per the README 'Verifying Signed Kaniko Images' section. Docs: https://github.com/GoogleContainerTools/kaniko