kaniko - Build Images In Kubernetes

!kaniko logo

kaniko is a tool to build container images from a Dockerfile, inside a container or Kubernetes cluster.

[!IMPORTANT]

This is a supported replacement of the original GoogleContainerTools/kaniko

repository, which was archived in June of 2025.

The focus of this fork is to keep dependencies up-to-date, fix bugs and improve performance.

The images are available on docker hub martizih/kaniko.

News and blog posts are on osscontainertools.org.

If you are new here you can refer to our Changelog Overview for the main differences to Google's v1.24.0 release.

kaniko doesn't depend on a Docker daemon and executes each command within a Dockerfile completely in userspace. This enables building container images in environments that can't easily or securely run a Docker daemon, such as a standard Kubernetes cluster.

kaniko is meant to be run as an image: ghcr.io/osscontainertools/kaniko:latest. We do not recommend running the kaniko executor binary in another image, as it might not work as you expect - see Known Issues.

Table of Contents _generated with DocToc_

• kaniko - Build Images In Kubernetes

Community

If you are interested in contributing to kaniko, learn more from our development and contributing guides.

For any community discussion participate in open issues or file a new issue.

Join our official chat on Matrix at #kaniko:matrix.org. It has dedicated rooms for #support@kaniko:matrix.org and #announcements@kaniko:matrix.org. We will also continue to monitor discussions in the #kaniko on Kubernetes Slack.

Sponsorships

Corporations

L3montree

We thank L3montree for their generous support and commitment to open-source sustainability.

Siemens

We thank Siemens for their generous support, and especially the team behind opensource.siemens.com.

Individuals

Sped0n

bootc

We are grateful for your support.

Alternatives

Chainguard forked kaniko and continues to maintain the project as https://github.com/chainguard-dev/kaniko. Chainguard is a company founded by the original authors of kaniko and hence it is a project dear to their heart. Their focus is to keep dependencies up to date and patch security issues, keeping kaniko more or less as-is feature wise. They do not release images publicly, only to chainguard customers. However, there is good guidance on how to build kaniko yourself from their source-only releases.

Releases

kaniko releases are published as images on ghcr.io/osscontainertools/kaniko and on Docker Hub as martizih/kaniko.

Release notes and source code archives are available on the releases section. For the release cadence and feature flag graduation policy, see docs/releases.md.

Images available from other vendors:

• kaniko-build organization

How does kaniko work?

The kaniko executor image is responsible for building an image from a Dockerfile and pushing it to a registry. Within the executor image, we extract the filesystem of the base image (the FROM image in the Dockerfile). We then execute the commands in the Dockerfile, snapshotting the filesystem in userspace after each one. After each command, we append a layer of changed files to the base image (if there are any) and update image metadata.

Known Issues

• kaniko does not support building Windows containers.
• Running kaniko in any Docker image other than the official kaniko image is not

• kaniko does not support the v1 Registry API

Demo

!Demo

Tutorial

For a detailed example of kaniko with local storage, please refer to a getting started tutorial.

Please see References for more docs & video tutorials

Using kaniko

To use kaniko to build and push an image for you, you will need:

1. A build context, aka something to build
2. A running instance of kaniko

kaniko Build Contexts

kaniko's build context is very similar to the build context you would send your Docker daemon for an image build; it represents a directory containing a Dockerfile which kaniko will use to build your image. For example, a COPY command in your Dockerfile should refer to a file in the build context.

You will need to store your build context in a place that kaniko can access. Right now, kaniko supports these storage solutions:

• GCS Bucket
• S3 Bucket
• Azure Blob Storage
• Local Directory
• Local Tar
• Standard Input
• Git Repository

_Note about Local Tar: this option refers to a tar gz file within the kaniko container. If you wish to use this option, you will need to mount in your build context into the container as a file._

_Note about Standard Input: the only Standard Input allowed by kaniko is in .tar.gz format._

If using a GCS or S3 bucket, you will first need to create a compressed tar of your build context and upload it to your bucket. Once running, kaniko will then download and unpack the compressed tar of the build context before starting the image build.

To create a compressed tar, you can run:

tar -C <path to build context> -zcvf context.tar.gz .

Then, copy over the compressed tar into your bucket. For example, we can copy over the compressed tar to a GCS bucket with gsutil:

gsutil cp context.tar.gz gs://<bucket name>

When running kaniko, use the --context flag with the appropriate prefix to specify the location of your build context:

| Source | Prefix | Example | | ------------------ | --------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | Local Directory | dir://[path to a directory in the kaniko container] | dir:///workspace | | Local Tar Gz | tar://[path to a .tar.gz in the kaniko container] | tar:///path/to/context.tar.gz | | Standard Input | tar://[stdin] | tar://stdin | | GCS Bucket | gs://[bucket name]/[path to .tar.gz] | gs://kaniko-bucket/path/to/context.tar.gz | | S3 Bucket | s3://[bucket name]/[path to .tar.gz] | s3://kaniko-bucket/path/to/context.tar.gz | | Azure Blob Storage | https://[account].[azureblobhostsuffix]/[container]/[path to .tar.gz] | https://myaccount.blob.core.windows.net/container/path/to/context.tar.gz | | Git Repository | git://[repository url][#reference][#commit-id] | git://github.com/acme/myproject.git#refs/heads/mybranch# |

If you don't specify a prefix, kaniko will assume a local directory. For example, to use a GCS bucket called kaniko-bucket, you would pass in --context=gs://kaniko-bucket/path/to/context.tar.gz.

Using Azure Blob Storage

If you are using Azure Blob Storage for context file, you will need to pass Azure Storage Account Access Key as an environment variable named AZURE_STORAGE_ACCESS_KEY through Kubernetes Secrets

Using Private Git Repository

You can use Personal Access Tokens for Build Contexts from Private Repositories from GitHub.

You can either pass this in as part of the git URL (e.g., git://[email protected]/acme/myproject.git#refs/heads/mybranch) or using the environment variable GIT_TOKEN.

You can also pass GIT_USERNAME and GIT_PASSWORD (password being the token) if you want to be explicit about the username.

Using Standard Input

If running kaniko and using Standard Input build context, you will need to add the docker or kubernetes -i, --interactive flag. Once running, kaniko will then get the data from STDIN and create the build context as a compressed tar. It will then unpack the compressed tar of the build context before starting the image build. If no data is piped during the interactive run, you will need to send the EOF signal by yourself by pressing Ctrl+D.

Complete example of how to interactively run kaniko with .tar.gz Standard Input data, using docker:

echo -e 'FROM alpine \nRUN echo "created from standard input"' > Dockerfile | tar -cf - Dockerfile | gzip -9 | docker run \
  --interactive -v $(pwd):/workspace ghcr.io/osscontainertools/kaniko:latest \
  --context tar://stdin \
  --destination=<YOUR-REGISTRY>/$project/$image:$tag>

Complete example of how to interactively run kaniko with .tar.gz Standard Input data, using Kubernetes command line with a temporary container and completely dockerless:

echo -e 'FROM alpine \nRUN echo "created from standard input"' > Dockerfile | tar -cf - Dockerfile | gzip -9 | kubectl run kaniko \
--rm --stdin=true \
--image=ghcr.io/osscontainertools/kaniko:latest --restart=Never \
--overrides='{
  "apiVersion": "v1",
  "spec": {
    "containers": [
      {
        "name": "kaniko",
        "image": "ghcr.io/osscontainertools/kaniko:latest",
        "stdin": true,
        "stdinOnce": true,
        "args": [
          "--dockerfile=Dockerfile",
          "--context=tar://stdin",
          "--destination<YOUR-REGISTRY>/<YOUR-REPO>/my-image"
        ],
        "volumeMounts": [
          {
            "name": "cabundle",
            "mountPath": "/kaniko/ssl/certs/"
          },
          {
            "name": "docker-config",
            "mountPath": "/kaniko/.docker/"
          }
        ]
      }
    ],
    "volumes": [
      {
        "name": "cabundle",
        "configMap": {
          "name": "cabundle"
        }
      },
      {
        "name": "docker-config",
        "configMap": {
          "name": "docker-config"
        }
      }
    ]
  }
}'

Running kaniko

There are several different ways to deploy and run kaniko:

• In a Kubernetes cluster
• In gVisor
• In Google Cloud Build
• In Docker

Running kaniko in a Kubernetes cluster

Requirements:

• Standard Kubernetes cluster (e.g. using

• Kubernetes Secret
• A build context

To run kaniko in a Kubernetes cluster, you will need a standard running Kubernetes cluster and a Kubernetes secret, which contains the auth required to push the final image.

To create a secret to authenticate to Google Cloud Registry, follow these steps:

1. Create a service account in the Google Cloud Console project you want to push

1. Download a JSON key for this service account
2. Rename the key to kaniko-secret.json
3. To create the secret, run:

kubectl create secret generic kaniko-secret --from-file=<path to kaniko-secret.json>

_Note: If using a GCS bucket in the same GCP project as a build context, this service account should now also have permissions to read from that bucket._

The Kubernetes Pod spec should look similar to this, with the args parameters filled in:

apiVersion: v1
kind: Pod
metadata:
  name: kaniko
spec:
  containers:
    - name: kaniko
      image: ghcr.io/osscontainertools/kaniko:latest
      args:
        - "--dockerfile=<path to Dockerfile within the build context>"
        - "--context=gs://<GCS bucket>/<path to .tar.gz>"
        - "--destination=<<YOUR-REGISTRY>/$PROJECT/$IMAGE:$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

This example pulls the build context from a GCS bucket. To use a local directory build context, you could consider using configMaps to mount in small build contexts.

Running kaniko in gVisor

Running kaniko in gVisor provides an additional security boundary. You will need to add the --force flag to run kaniko in gVisor, since currently there isn't a way to determine whether or not a container is running in gVisor.

docker run --runtime=runsc -v $(pwd):/workspace -v ~/.config:/root/.config \
ghcr.io/osscontainertools/kaniko:latest \
--dockerfile=<path to Dockerfile> --context=/workspace \
--destination=<YOUR-REGISTRY>/<YOUR-REPO>/my-image --force

We pass in --runtime=runsc to use gVisor. This example mounts the current directory to /workspace for the build context and the ~/.config directory for GCR credentials.

Running kaniko in Google Cloud Build

Requirements:

• A build context

steps:
  - name: ghcr.io/osscontainertools/kaniko:latest
    args:
      [
        "--dockerfile=<path to Dockerfile within the build context>",
        "--context=dir://<path to build context>",
        "--destination=<<YOUR-REGISTRY>/$PROJECT/$IMAGE:$TAG>",
      ]

kaniko will build and push the final image in this build step.

Running kaniko in Docker

Requirements:

• Docker

For example, when using gcloud and GCR you could run kaniko as follows:

docker run \
    -v "$HOME"/.config/gcloud:/root/.config/gcloud \
    -v /path/to/context:/workspace \
    ghcr.io/osscontainertools/kaniko:latest \
    --dockerfile /workspace/Dockerfile \
    --destination "gcr.io/$PROJECT_ID/$IMAGE_NAME:$TAG" \
    --context dir:///workspace/

There is also a utility script run_in_docker.sh that can be used as follows:

./run_in_docker.sh <path to Dockerfile> <path to build context> <destination of final image>

_NOTE: run_in_docker.sh expects a path to a Dockerfile relative to the absolute path of the build context._

An example run, specifying the Dockerfile in the container directory /workspace, the build context in the local directory /home/user/kaniko-project, and a Google Container Registry as a remote image destination:

./run_in_docker.sh /workspace/Dockerfile /home/user/kaniko-project gcr.io/$PROJECT_ID/$TAG

Bootstrapping Kaniko

The good news is, it's all technically possible, but it's a bit more involved than building other images.

The first problem we face is that the kaniko binaries are installed in /kaniko directory. Which means that this directory must also be ignored during snapshots, lest we would leak our build tool into any image we produce. But this also means that kaniko by default can't build a kaniko image with the binaries installed in /kaniko directory. Luckily there is an override for that, that allows us to move all the binaries to a different location before the build ie. KANIKO_DIR=/kaniko2.

The second problem only affects build using the debug image, ie. gitlab-runner. The shell that is spawned in the debug image is in /busybox, similarly we can't snapshot files in that directory. Unfortunately there is no override to move those binaries. But with a bit creativity we can create a bootstrap image that has the shell installed into a different location ie. /busybox2 and then use that bootstrap image to build the actual new debug image.

bootstrap:
  extends:
    - .build
  image:
    name: gcr.io/kaniko-project/executor:v1.24.0-debug
    entrypoint: [""]
  needs: []
  variables:
    IMAGE: ${CI_REGISTRY_IMAGE}/bootstrap:latest
    EXTRA_ARGS: >-
      --build-arg=TARGETARCH=amd64
      --build-arg=TARGETOS=linux
      --target=kaniko-debug-2
    KANIKO_DIR: /kaniko2
build:
  extends:
    - .build
  image:
    name: ${CI_REGISTRY_IMAGE}/bootstrap:latest
    entrypoint: [""]
  needs: [bootstrap]
  variables:
    IMAGE: ${CI_REGISTRY_IMAGE}/kaniko:latest
    EXTRA_ARGS: >-
      --build-arg=TARGETARCH=amd64
      --build-arg=TARGETOS=linux
      --target=kaniko-debug
    KANIKO_DIR: /kaniko2

With this two step approach we can now indeed bootstrap kaniko in kaniko. However, it is not really necessary to rebuild that intermediate bootstrap image every time, we can reuse it from a different build. Hence I provide a dedicated image ghcr.io/osscontainertools/kaniko:bootstrap that can be used for that purpose.

Caching

Caching Layers

kaniko can cache layers created by RUN(configured by flag --cache-run-layers) and COPY (configured by flag --cache-copy-layers) commands in a remote repository. Before executing a command, kaniko checks the cache for the layer. If it exists, kaniko will pull and extract the cached layer instead of executing the command. If not, kaniko will execute the command and then push the newly created layer to the cache.

Note that kaniko cannot read layers from the cache after a cache miss: once a layer has not been found in the cache, all subsequent layers are built locally without consulting the cache.

Users can opt into caching by setting the --cache=true flag. A remote repository for storing cached layers can be provided via the --cache-repo flag. If this flag isn't provided, a cached repo will be inferred from the --destination provided.

Caching Base Images

kaniko can cache images in a local directory that can be volume mounted into the kaniko pod. To do so, the cache must first be populated, as it is read-only. We provide a kaniko cache warming image at gcr.io/kaniko-project/warmer:

docker run -v $(pwd):/workspace ghcr.io/osscontainertools/kaniko:warmer --cache-dir=/workspace/cache --image=<image to cache> --image=<another image to cache>
docker run -v $(pwd):/workspace ghcr.io/osscontainertools/kaniko:warmer --cache-dir=/workspace/cache --dockerfile=<path to dockerfile>
docker run -v $(pwd):/workspace ghcr.io/osscontainertools/kaniko:warmer --cache-dir=/workspace/cache --dockerfile=<path to dockerfile> --build-arg version=1.19

--image can be specified for any number of desired images. --dockerfile can be specified for the path of dockerfile for cache.These command will combined to cache those images by digest in a local directory named cache. Once the cache is populated, caching is opted into with the same --cache=true flag as above. The location of the local cache is provided via the --cache-dir flag, defaulting to /cache as with the cache warmer. See the examples directory for how to use with kubernetes clusters and persistent cache volumes.

Pushing to Different Registries

For registry-specific setup instructions (Docker Hub, GCR, ECR, ACR, JFrog, registry mirrors and maps) see docs/registries.md.

Subcommands

In addition to the default build-and-push flow, the executor binary exposes a small set of subcommands.

Subcommand login

executor login stores registry credentials in the Docker config file at $DOCKER_CONFIG/config.json (the executor image sets DOCKER_CONFIG=/kaniko/.docker/), so subsequent executor invocations can authenticate to the registry without a credential helper.

Flags:

• -u, --username — username for the registry (required).
• -p, --password — password or token; mutually exclusive with --password-stdin.
• --password-stdin — read the password from standard input; useful for piping a secret without exposing it in the process list.

Subcommand push

executor push --destination reads a pre-built image and pushes it to one or more registries, skipping the build entirely. The path may point at a docker-save format tarball produced by --tar-path or at an OCI image layout directory produced by --oci-layout-path. All registry, auth, retry, and digest-file flags are the same as on the build command. See the canonical workflow under --tar-path.

The artifact must contain exactly one image. Multi-image tarballs and indexes are not supported.

Subcommand bake

executor bake [target] builds several images from one multi-stage Dockerfile in a single invocation. A small HCL bakefile says which stage each image is built from and where it is pushed, while the context, dockerfile, build args, cache and registry settings stay on the usual flags and are shared by every target.

target "app" {
  destination = ["registry.example.com/app:latest"]
}
target "tools" {
  destination = ["registry.example.com/tools:latest"]
}

It is the analogue of a docker-bake.hcl, expressed in kaniko's commands rather than buildx's, which also means a docker-bake.hcl will not parse. For the format, choosing targets, and overriding destinations with --set, see docs/bakefile.md.

Additional Flags

Flag --build-arg

This flag allows you to pass in ARG values at build time, similarly to Docker. You can set it multiple times for multiple arguments.

Note that passing values that contain spaces is not natively supported - you need to ensure that the IFS is set to null before your executor command. You can set this by adding export IFS='' before your executor call. See the following example

export IFS=''
/kaniko/executor --build-arg "MY_VAR='value with spaces'" ...

Flag --cache

Set this flag as --cache=true to opt into caching with kaniko.

Flag --cache-dir

Set this flag to specify a local directory cache for base images. Defaults to /cache.

_This flag must be used in conjunction with the --cache=true flag._

Flag --cache-repo

Set this flag to specify a remote repository that will be used to store cached layers.

If this flag is not provided, a cache repo will be inferred from the --destination flag. If --destination=gcr.io/kaniko-project/test, then cached layers will be stored in gcr.io/kaniko-project/test/cache.

_This flag must be used in conjunction with the --cache=true flag._

Flag --cache-copy-layers

Set this flag to cache copy layers.

Flag --cache-run-layers

Set this flag to cache run layers (default=true).

Flag --cache-ttl

Cache timeout in hours. Defaults to two weeks.

Flag --pre-cleanup

Set this flag to clean the filesystem before the build. ie. in order to support custom built kaniko images.

Defaults to false. Can also be set via the KANIKO_PRE_CLEANUP environment variable.

Flag --cleanup

Set this flag to clean the filesystem and kaniko's working directory at the end of the build.

Defaults to false. Can also be set via the KANIKO_CLEANUP environment variable.

Flag --compression

Use this flag to select the compression algorithm [gzip, zstd]. Defaults to gzip.

Flag --compression-level

Use this flag to select the compression level. When it is not set, layers compress at the fastest level of the selected codec.

For --compression=gzip the level runs from -2 to 9, see compress/gzip.

For --compression=zstd the level runs from 1 to 22 and maps onto four encoder presets, see EncoderLevelFromZstd.

Flag --image-format

Use this flag to select the output image media type [docker, oci]. docker writes a Docker schema2 manifest, oci writes an OCI image manifest. When unset, kaniko inherits the format of the base image. A base image that mixes OCI and docker media types is inherited as it is, set this flag to unify the output on one of them.

Flag --compressed-caching

Set this to false in order to prevent tar compression for cached layers. This will increase the runtime of the build, but decrease the memory usage especially for large builds. Try to use --compressed-caching=false if your build fails with an out of memory error. Defaults to true.

Flag --context-sub-path

Set a sub path within the given --context.

Its particularly useful when your context is, for example, a git repository, and you want to build one of its subfolders instead of the root folder.

Flag --credential-helpers

Use these credential helpers automatically, select from (env, google, ecr, acr, gitlab). Set it repeatedly for multiple helpers, defaults to all, set it to empty string to deactivate.

Flag --custom-platform

Allows to build with another default platform than the host, similarly to docker build --platform xxx the value has to be on the form --custom-platform=linux/arm, with acceptable values listed here: GOOS/GOARCH.

It's also possible specifying CPU variants adding it as a third parameter (like --custom-platform=linux/arm/v5). Currently CPU variants are only known to be used for the ARM architecture as listed here: GOARM

_The resulting images cannot provide any metadata about CPU variant due to a limitation of the OCI-image specification._

_This is not virtualization and cannot help to build an architecture not natively supported by the build host. This is used to build i386 on an amd64 Host for example, or arm32 on an arm64 host._

Flag --digest-file

Set this flag to specify a file in the container. This file will receive the digest of a built image. This can be used to automatically track the exact image built by kaniko.

For example, setting the flag to --digest-file=/dev/termination-log will write the digest to that file, which is picked up by Kubernetes automatically as the {{.state.terminated.message}} of the container.

Flag --dockerfile

Path to the dockerfile to be built. (default "Dockerfile")

Flag --dryrun

Instead of building the docker image, just print a plan of what kaniko would do.

Flag --force

Force building outside of a container

Flag --git

Branch to clone if build context is a git repository (default branch=,single-branch=false,depth=0,recurse-submodules=false,insecure-skip-tls=false)

Flag --image-name-with-digest-file

Specify a file to save the image name w/ digest of the built image to.

Flag --image-name-tag-with-digest-file

Specify a file to save the image name w/ image tag and digest of the built image to.

Flag --insecure

Set this flag if you want to push images to a plain HTTP registry. It is supposed to be used for testing purposes only and should not be used in production!

Flag --insecure-pull

Set this flag if you want to pull images from a plain HTTP registry. It is supposed to be used for testing purposes only and should not be used in production!

Flag --insecure-registry

You can set --insecure-registry to use plain HTTP requests when accessing the specified registry. It is supposed to be used for testing purposes only and should not be used in production! You can set it multiple times for multiple registries.

Flag --kaniko-dir

Set this flag as --kaniko-dir /not-kaniko to move the kaniko binaries to /not-kaniko before the build starts. This is helpful in Bootstrapping Kaniko. Will be deprecated in v1.28.0. Use the env variable KANIKO_DIR instead.

Flag --label

Set this flag as --label key=value to set some metadata to the final image. This is equivalent as using the LABEL within the Dockerfile.

Flag --annotation

Set this flag as --annotation key=value to set some metadata to the final image. Annotation levels are currently not supported and it's always the manifest that's annotated.

Flag --log-format

Set this flag as --log-format= to set the log format. Defaults to color.

Flag --log-timestamp

Set this flag as --log-timestamp= to add timestamps to log format. Defaults to false.

Flag --materialize

Set this boolean flag to true if you want kaniko to ensure that the filesystem is in a well-defined state after the build finishes. If you have a 100% cache-hitrate kaniko can skip unpacking files to the filesystem as it is superfluous if the goal is to simply build an image and push it to registry, but this also means that state of the filesystem after the build depends on whether that optimization was possible or not. This option disables this optimization entirely making sure that the filesystem is always well-defined.

This is useful if you use kaniko not to build a docker image, but to initialize your environment.

Defaults to false

Flag --no-push

Set this flag if you only want to build the image, without pushing to a registry. This can also be defined through KANIKO_NO_PUSH environment variable.

NOTE: this will still push cache layers to the repo, to disable pushing cache layers use --no-push-cache

Flag --no-push-cache

Set this flag if you do not want to push cache layers to a registry. Can be used in addition to --no-push to push no layers to a registry.

Flag --oci-layout-path

Set this flag to specify a directory in the container where the OCI image layout of a built image will be placed. This can be used to automatically track the exact image built by kaniko.

For example, to surface the image digest built in a Tekton task, this flag should be set to match the image resource outputImageDir.

_Note: Depending on the built image, the media type of the image manifest might be either application/vnd.oci.image.manifest.v1+json or application/vnd.docker.distribution.manifest.v2+json._

Flag --preserve-context

Set this boolean flag to true if you want kaniko to restore the build-context for multi-stage builds. If set, kaniko will take a snapshot of the full filesystem before it starts building to later restore to that state. If combined with the --cleanup flag it will also restore the state after cleanup. If combined with --pre-cleanup it will not restore the state in between stages.

This is useful if you want to pass in secrets via files or if you want to execute commands after the build completes.

It will only take the snapshot if we are building a multistage image or if we plan to cleanup the filesystem either before or after the build.

Defaults to false. Can also be set via KANIKO_PRESERVE_CONTEXT environment variable.

Flag --push-ignore-immutable-tag-errors

Set this boolean flag to true if you want the Kaniko process to exit with success when a push error related to tag immutability occurs.

This is useful for example if you have parallel builds pushing the same tag and do not care which one actually succeeds.

Defaults to false.

Flag --push-retry

Set this flag to the number of retries that should happen for the push of an image to a remote destination. Defaults to 0.

Flag --registry-certificate

Set this flag to provide a certificate for TLS communication with a given registry.

Expected format is my.registry.url=/path/to/the/certificate.cert

Flag --registry-client-cert

Set this flag to provide a certificate/key pair for mutual TLS (mTLS) communication with a given registry that requires mTLS for authentication.

Expected format is my.registry.url=/path/to/client/cert.crt,/path/to/client/key.key

Flag --registry-map

Set this flag if you want to remap registries references. Useful for air gap environment for example. You can use this flag more than once, if you want to set multiple mirrors for a given registry. You can mention several remap in a single flag too, separated by semi-colon. If an image is not found on the first mirror, Kaniko will try the next mirror(s), and at the end fallback on the original registry.

Registry maps can also be defined through KANIKO_REGISTRY_MAP environment variable.

Expected format is original-registry=remapped-registry[;another-reg=another-remap[;...]] for example.

Note that you can specify a URL with scheme for this flag. Some valid options are:

• index.docker.io=mirror.gcr.io
• gcr.io=127.0.0.1
• quay.io=192.168.0.1:5000
• index.docker.io=docker-io.mirrors.corp.net;index.docker.io=mirror.gcr.io;gcr.io=127.0.0.1

• docker.io=harbor.private.io/theproject

Flag --registry-mirror

Set this flag if you want to use a registry mirror instead of the default index.docker.io. You can use this flag more than once, if you want to set multiple mirrors. If an image is not found on the first mirror, Kaniko will try the next mirror(s), and at the end fallback on the default registry.

Mirror can also be defined through KANIKO_REGISTRY_MIRROR environment variable.

Expected format is mirror.gcr.io or mirror.gcr.io/path for example.

Note that you can specify a URL with scheme for this flag. Some valid options are:

• mirror.gcr.io
• 127.0.0.1
• 192.168.0.1:5000
• mycompany-docker-virtual.jfrog.io
• harbor.private.io/theproject

Flag --skip-default-registry-fallback

Set this flag if you want the build process to fail if none of the mirrors listed in flag registry-mirror can pull some image. This should be used with mirrors that implements a whitelist or some image restrictions.

If registry-mirror is not set or is empty, this flag is ignored.

Flag --reproducible

Set this flag to strip timestamps out of the built image and make it reproducible.

Flag --secret

Set this flag as --secret id=MY_SECRET[,src=/file][,env=VAR][,type=file|env] to configure build-secrets to be used during the build.

[!IMPORTANT]

The secret is not stored securely during the build and may be recoverable by other RUN steps even without explicitly mounting it. It should therefore not be considered confidential within the context of the build. The secret is never added to the image and never pushed.

Flag --single-snapshot

This flag takes a single snapshot of the filesystem at the end of the build, so only one layer will be appended to the base image.

Flag --skip-push-permission-check

Set this flag to skip push permission check. This can be useful to delay Kanikos first request for delayed network-policies.

Flag --skip-tls-verify

Set this flag to skip TLS certificate validation when pushing to a registry. It is supposed to be used for testing purposes on

... (README truncated for length)