[{"_1":2,"_160":-5,"_161":-5},"loaderData",{"_3":4,"_17":18,"_25":26,"_139":140},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7,"_13":14,"_15":16},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","theme","system","contrast","normal","routes/_layout",{"_19":-5,"_20":21,"_22":21,"_23":11,"_24":21},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_27":28,"_29":-5,"_30":11,"_31":11,"_32":33,"_34":35,"_36":-5,"_37":11,"_38":39,"_88":-5,"_89":90,"_128":-5,"_129":11,"_130":21,"_131":11,"_132":-5,"_133":11,"_134":-5,"_135":136,"_137":91,"_138":-7},"canonicalUrl","https://hub.docker.com/r/avenda/kaniko/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","avenda","reponame","kaniko","cloudBuildSource","isAutobuildsAvailable","repo",{"_40":41,"_42":43,"_45":46,"_47":48,"_49":11,"_50":51,"_52":53,"_54":55,"_57":35,"_32":33,"_58":59,"_60":44,"_61":62,"_63":64,"_65":66,"_67":-5,"_68":62,"_69":70,"_71":11,"_72":33,"_73":74,"_79":11,"_80":81,"_85":33,"_86":87},"categories",[],"content_types",[44],"image","date_registered","2020-03-31T21:01:09.958891Z","description","","is_private","last_updated","2020-04-01T14:40:10.305588Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[56],"application/vnd.docker.container.image.v1+json","name","pull_count",254,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","# kaniko - Build Images In Kubernetes\n\n[![Build Status](https://travis-ci.org/GoogleContainerTools/kaniko.svg?branch=master)](https://travis-ci.org/GoogleContainerTools/kaniko)\n\n![kaniko logo](logo/Kaniko-Logo.png)\n\nkaniko is a tool to build container images from a Dockerfile, inside a container or Kubernetes cluster. \n\nkaniko doesn't depend on a Docker daemon and executes each command within a Dockerfile completely in userspace.\nThis enables building container images in environments that can't easily or securely run a Docker daemon, such as a standard Kubernetes cluster.\n\nkaniko is meant to be run as an image: `gcr.io/kaniko-project/executor`. We do **not** recommend running the kaniko executor binary in another image, as it might not work.\n\nWe'd love to hear from you! Join us on [#kaniko Kubernetes Slack](https://kubernetes.slack.com/messages/CQDCHGX7Y/)\n\n:mega: **Please fill out our [quick 5-question survey](https://forms.gle/HhZGEM33x4FUz9Qa6)** so that we can learn how satisfied you are with Kaniko, and what improvements we should make. Thank you! :dancers:\n\nKaniko is not an officially supported Google project. \n\n_If you are interested in contributing to kaniko, see [DEVELOPMENT.md](DEVELOPMENT.md) and [CONTRIBUTING.md](CONTRIBUTING.md)._\n\n\n\n\n**Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)*\n\n- [Community](#community)\n- [How does kaniko work?](#how-does-kaniko-work)\n- [Known Issues](#known-issues)\n- [Demo](#demo)\n- [Tutorial](#tutorial)\n- [Using kaniko](#using-kaniko)\n - [kaniko Build Contexts](#kaniko-build-contexts)\n - [Using Azure Blob Storage](#using-azure-blob-storage)\n - [Using Private Git Repository](#using-private-git-repository)\n - [Running kaniko](#running-kaniko)\n - [Running kaniko in a Kubernetes cluster](#running-kaniko-in-a-kubernetes-cluster)\n - [Kubernetes secret](#kubernetes-secret)\n - [Running kaniko in gVisor](#running-kaniko-in-gvisor)\n - [Running kaniko in Google Cloud Build](#running-kaniko-in-google-cloud-build)\n - [Running kaniko in Docker](#running-kaniko-in-docker)\n - [Caching](#caching)\n - [Caching Layers](#caching-layers)\n - [Caching Base Images](#caching-base-images)\n - [Pushing to Different Registries](#pushing-to-different-registries)\n - [Pushing to Docker Hub](#pushing-to-docker-hub)\n - [Pushing to Amazon ECR](#pushing-to-amazon-ecr)\n - [Additional Flags](#additional-flags)\n - [--build-arg](#--build-arg)\n - [--cache](#--cache)\n - [--cache-dir](#--cache-dir)\n - [--cache-repo](#--cache-repo)\n - [--digest-file](#--digest-file)\n - [--oci-layout-path](#--oci-layout-path)\n - [--insecure-registry](#--insecure-registry)\n - [--skip-tls-verify-registry](#--skip-tls-verify-registry)\n - [--cleanup](#--cleanup)\n - [--insecure](#--insecure)\n - [--insecure-pull](#--insecure-pull)\n - [--no-push](#--no-push)\n - [--registry-mirror](#--registry-mirror)\n - [--reproducible](#--reproducible)\n - [--single-snapshot](#--single-snapshot)\n - [--skip-tls-verify](#--skip-tls-verify)\n - [--skip-tls-verify-pull](#--skip-tls-verify-pull)\n - [--snapshotMode](#--snapshotmode)\n - [--target](#--target)\n - [--tarPath](#--tarpath)\n - [--verbosity](#--verbosity)\n - [--whitelist-var-run](#--whitelist-var-run)\n - [--label](#--label)\n - [Debug Image](#debug-image)\n- [Security](#security)\n- [Comparison with Other Tools](#comparison-with-other-tools)\n- [Community](#community-1)\n- [Limitations](#limitations)\n - [mtime and snapshotting](#mtime-and-snapshotting)\n\n\n\n## Community\nWe'd love to hear from you! Join [#kaniko on Kubernetes Slack](https://kubernetes.slack.com/messages/CQDCHGX7Y/)\n\n## How does kaniko work?\n\nThe kaniko executor image is responsible for building an image from a Dockerfile and pushing it to a registry.\nWithin the executor image, we extract the filesystem of the base image (the FROM image in the Dockerfile).\nWe then execute the commands in the Dockerfile, snapshotting the filesystem in userspace after each one.\nAfter each command, we append a layer of changed files to the base image (if there are any) and update image metadata.\n\n## Known Issues\n\n* kaniko does not support building Windows containers.\n* Running kaniko in any Docker image other than the official kaniko image is not supported (ie YMMV).\n * This includes copying the kaniko executables from the official image into another image.\n* kaniko does not support the v1 Registry API ([Registry v1 API Deprecation](https://engineering.docker.com/2019/03/registry-v1-api-deprecation/))\n\n## Demo\n\n![Demo](/docs/demo.gif)\n\n## Tutorial\n\nFor a detailed example of kaniko with local storage, please refer to a [getting started tutorial](./docs/tutorial.md).\n\n## Using kaniko\n\nTo use kaniko to build and push an image for you, you will need:\n\n1. A [build context](#kaniko-build-contexts), aka something to build\n2. A [running instance of kaniko](#running-kaniko)\n\n### kaniko Build Contexts\n\nkaniko'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.\nFor example, a `COPY` command in your Dockerfile should refer to a file in the build context.\n\nYou will need to store your build context in a place that kaniko can access.\nRight now, kaniko supports these storage solutions:\n- GCS Bucket\n- S3 Bucket\n- Azure Blob Storage\n- Local Directory\n- Git Repository\n\n_Note: the local directory option refers to a directory within the kaniko container.\nIf you wish to use this option, you will need to mount in your build context into the container as a directory._\n\nIf 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.\nOnce running, kaniko will then download and unpack the compressed tar of the build context before starting the image build.\n\nTo create a compressed tar, you can run:\n\n```shell\ntar -C -zcvf context.tar.gz .\n```\nThen, copy over the compressed tar into your bucket.\nFor example, we can copy over the compressed tar to a GCS bucket with gsutil:\n\n```shell\ngsutil cp context.tar.gz gs://\n```\n\nWhen running kaniko, use the `--context` flag with the appropriate prefix to specify the location of your build context:\n\n| Source | Prefix | Example |\n|---------|---------|---------|\n| Local Directory | dir://[path to a directory in the kaniko container] | `dir:///workspace` |\n| Local Tar Gz | tar://[path to a .tar.gz in the kaniko container] | `tar://path/to/context.tar.gz` |\n| GCS Bucket | gs://[bucket name]/[path to .tar.gz] | `gs://kaniko-bucket/path/to/context.tar.gz` |\n| S3 Bucket | s3://[bucket name]/[path to .tar.gz] | `s3://kaniko-bucket/path/to/context.tar.gz` |\n| Azure Blob Storage| https://[account].[azureblobhostsuffix]/[container]/[path to .tar.gz] | `https://myaccount.blob.core.windows.net/container/path/to/context.tar.gz` |\n| Git Repository | git://[repository url][#reference] | `git://github.com/acme/myproject.git#refs/heads/mybranch` |\n\nIf you don't specify a prefix, kaniko will assume a local directory.\nFor example, to use a GCS bucket called `kaniko-bucket`, you would pass in `--context=gs://kaniko-bucket/path/to/context.tar.gz`.\n\n### Using Azure Blob Storage\nIf you are using Azure Blob Storage for context file, you will need to pass [Azure Storage Account Access Key](https://docs.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string?toc=%2fazure%2fstorage%2fblobs%2ftoc.json) as an environment variable named `AZURE_STORAGE_ACCESS_KEY` through Kubernetes Secrets\n\n### Using Private Git Repository\nYou can use `Personal Access Tokens` for Build Contexts from Private Repositories from [GitHub](https://blog.github.com/2012-09-21-easier-builds-and-deployments-using-git-over-https-and-oauth/).\n\n### Running kaniko\n\nThere are several different ways to deploy and run kaniko:\n\n- [In a Kubernetes cluster](#running-kaniko-in-a-kubernetes-cluster)\n- [In gVisor](#running-kaniko-in-gvisor)\n- [In Google Cloud Build](#running-kaniko-in-google-cloud-build)\n- [In Docker](#running-kaniko-in-docker)\n\n#### Running kaniko in a Kubernetes cluster\n\nRequirements:\n\n- Standard Kubernetes cluster (e.g. using [GKE](https://cloud.google.com/kubernetes-engine/))\n- [Kubernetes Secret](#kubernetes-secret)\n- A [build context](#kaniko-build-contexts)\n\n##### Kubernetes secret\n\nTo 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.\n\nTo create a secret to authenticate to Google Cloud Registry, follow these steps:\n1. Create a service account in the Google Cloud Console project you want to push the final image to with `Storage Admin` permissions.\n2. Download a JSON key for this service account\n3. Rename the key to `kaniko-secret.json`\n4. To create the secret, run:\n\n```shell\nkubectl create secret generic kaniko-secret --from-file=\n```\n\n_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._\n\nThe Kubernetes Pod spec should look similar to this, with the args parameters filled in:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n name: kaniko\nspec:\n containers:\n - name: kaniko\n image: gcr.io/kaniko-project/executor:latest\n args: [\"--dockerfile=\",\n \"--context=gs:///\",\n \"--destination=\"]\n volumeMounts:\n - name: kaniko-secret\n mountPath: /secret\n env:\n - name: GOOGLE_APPLICATION_CREDENTIALS\n value: /secret/kaniko-secret.json\n restartPolicy: Never\n volumes:\n - name: kaniko-secret\n secret:\n secretName: kaniko-secret\n```\n\nThis example pulls the build context from a GCS bucket.\nTo use a local directory build context, you could consider using configMaps to mount in small build contexts.\n\n#### Running kaniko in gVisor\n\nRunning kaniko in [gVisor](https://github.com/google/gvisor) provides an additional security boundary.\nYou 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.\n\n```shell\ndocker run --runtime=runsc -v $(pwd):/workspace -v ~/.config:/root/.config \\\ngcr.io/kaniko-project/executor:latest \\\n--dockerfile= --context=/workspace \\\n--destination=gcr.io/my-repo/my-image --force\n```\n\nWe pass in `--runtime=runsc` to use gVisor.\nThis example mounts the current directory to `/workspace` for the build context and the `~/.config` directory for GCR credentials.\n\n#### Running kaniko in Google Cloud Build\n\nRequirements:\n- A [build context](#kaniko-build-contexts)\n\nTo run kaniko in GCB, add it to your build config as a build step:\n\n```yaml\nsteps:\n - name: gcr.io/kaniko-project/executor:latest\n args: [\"--dockerfile=\",\n \"--context=dir://\",\n \"--destination=\"]\n```\n\nkaniko will build and push the final image in this build step.\n\n#### Running kaniko in Docker\n\nRequirements:\n\n- [Docker](https://docs.docker.com/install/)\n\nWe can run the kaniko executor image locally in a Docker daemon to build and push an image from a Dockerfile.\n\nFor example, when using gcloud and GCR you could run Kaniko as follows:\n```shell\ndocker run \\\n -v \"$HOME\"/.config/gcloud:/root/.config/gcloud \\\n -v /path/to/context:/workspace \\\n gcr.io/kaniko-project/executor:latest \\\n --dockerfile /workspace/Dockerfile\n --destination \"gcr.io/$PROJECT_ID/$IMAGE_NAME:$TAG\"\n --context dir:///workspace/\"\n```\n\nThere is also a utility script [`run_in_docker.sh`](./run_in_docker.sh) that can be used as follows:\n```shell\n./run_in_docker.sh \n```\n\n_NOTE: `run_in_docker.sh` expects a path to a \nDockerfile relative to the absolute path of the build context._\n\nAn example run, specifying the Dockerfile in the container directory `/workspace`, the build\ncontext in the local directory `/home/user/kaniko-project`, and a Google Container Registry\nas a remote image destination:\n\n```shell\n./run_in_docker.sh /workspace/Dockerfile /home/user/kaniko-project gcr.io/$PROJECT_ID/$TAG\n```\n\n### Caching\n\n#### Caching Layers\nkaniko can cache layers created by `RUN` commands in a remote repository.\nBefore executing a command, kaniko checks the cache for the layer.\nIf it exists, kaniko will pull and extract the cached layer instead of executing the command.\nIf not, kaniko will execute the command and then push the newly created layer to the cache.\n\nUsers can opt into caching by setting the `--cache=true` flag.\nA remote repository for storing cached layers can be provided via the `--cache-repo` flag.\nIf this flag isn't provided, a cached repo will be inferred from the `--destination` provided.\n\n#### Caching Base Images\n\nkaniko can cache images in a local directory that can be volume mounted into the kaniko pod.\nTo do so, the cache must first be populated, as it is read-only. We provide a kaniko cache warming\nimage at `gcr.io/kaniko-project/warmer`:\n\n```shell\ndocker run -v $(pwd):/workspace gcr.io/kaniko-project/warmer:latest --cache-dir=/workspace/cache --image= --image=\n```\n\n`--image` can be specified for any number of desired images.\nThis command will cache those images by digest in a local directory named `cache`.\nOnce the cache is populated, caching is opted into with the same `--cache=true` flag as above.\nThe location of the local cache is provided via the `--cache-dir` flag, defaulting to `/cache` as with the cache warmer.\nSee the `examples` directory for how to use with kubernetes clusters and persistent cache volumes.\n\n### Pushing to Different Registries\n\nkaniko uses Docker credential helpers to push images to a registry.\n\nkaniko comes with support for GCR, Docker `config.json` and Amazon ECR, but configuring another credential helper should allow pushing to a different registry.\n\n#### Pushing to Docker Hub\n\nGet your docker registry user and password encoded in base64\n\n echo -n USER:PASSWORD | base64\n\nCreate a `config.json` file with your Docker registry url and the previous generated base64 string\n\n```\n{\n\t\"auths\": {\n\t\t\"https://index.docker.io/v1/\": {\n\t\t\t\"auth\": \"xxxxxxxxxxxxxxx\"\n\t\t}\n\t}\n}\n```\n\nRun kaniko with the `config.json` inside `/kaniko/.docker/config.json`\n\n docker run -ti --rm -v `pwd`:/workspace -v `pwd`/config.json:/kaniko/.docker/config.json:ro gcr.io/kaniko-project/executor:latest --dockerfile=Dockerfile --destination=yourimagename\n\n#### Pushing to Amazon ECR\n\nThe Amazon ECR [credential helper](https://github.com/awslabs/amazon-ecr-credential-helper) is built into the kaniko executor image.\nTo configure credentials, you will need to do the following:\n\n1. Update the `credsStore` section of [config.json](https://github.com/awslabs/amazon-ecr-credential-helper#configuration):\n\n ```json\n { \"credsStore\": \"ecr-login\" }\n ```\n\n You can mount in the new config as a configMap:\n\n ```shell\n kubectl create configmap docker-config --from-file=\n ```\n\n2. Configure credentials\n\n 1. You can use instance roles when pushing to ECR from a EC2 instance or from EKS, by [configuring the instance role permissions](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_EKS.html).\n\n 2. Or you can create a Kubernetes secret for your `~/.aws/credentials` file so that credentials can be accessed within the cluster.\n To create the secret, run:\n ```shell\n kubectl create secret generic aws-secret --from-file=\n ```\n\nThe Kubernetes Pod spec should look similar to this, with the args parameters filled in.\nNote that `aws-secret` volume mount and volume are only needed when using AWS credentials from a secret, not when using instance roles.\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n name: kaniko\nspec:\n containers:\n - name: kaniko\n image: gcr.io/kaniko-project/executor:latest\n args: [\"--dockerfile=\",\n \"--context=s3:///\",\n \"--destination=\"]\n volumeMounts:\n - name: docker-config\n mountPath: /kaniko/.docker/\n # when not using instance role\n - name: aws-secret\n mountPath: /root/.aws/\n restartPolicy: Never\n volumes:\n - name: docker-config\n configMap:\n name: docker-config\n # when not using instance role\n - name: aws-secret\n secret:\n secretName: aws-secret\n```\n\n### Additional Flags\n\n#### --build-arg\n\nThis flag allows you to pass in ARG values at build time, similarly to Docker.\nYou can set it multiple times for multiple arguments.\n\n#### --cache\n\nSet this flag as `--cache=true` to opt into caching with kaniko.\n\n#### --cache-dir\n\nSet this flag to specify a local directory cache for base images. Defaults to `/cache`.\n\n_This flag must be used in conjunction with the `--cache=true` flag._\n\n#### --cache-repo\n\nSet this flag to specify a remote repository that will be used to store cached layers.\n\nIf this flag is not provided, a cache repo will be inferred from the `--destination` flag.\nIf `--destination=gcr.io/kaniko-project/test`, then cached layers will be stored in `gcr.io/kaniko-project/test/cache`.\n\n_This flag must be used in conjunction with the `--cache=true` flag._\n\n\n#### --digest-file\n\nSet this flag to specify a file in the container. This file will\nreceive the digest of a built image. This can be used to\nautomatically track the exact image built by Kaniko.\n\nFor example, setting the flag to `--digest-file=/dev/termination-log`\nwill write the digest to that file, which is picked up by\nKubernetes automatically as the `{{.state.terminated.message}}`\nof the container.\n\n#### --oci-layout-path\n\nSet this flag to specify a directory in the container where the OCI image\nlayout of a built image will be placed. This can be used to automatically\ntrack the exact image built by Kaniko.\n\nFor example, to surface the image digest built in a\n[Tekton task](https://github.com/tektoncd/pipeline/blob/v0.6.0/docs/resources.md#surfacing-the-image-digest-built-in-a-task),\nthis flag should be set to match the image resource `outputImageDir`.\n\n_Note: Depending on the built image, the media type of the image manifest might be either\n`application/vnd.oci.image.manifest.v1+json` or `application/vnd.docker.distribution.manifest.v2+json`._\n\n#### --insecure-registry\n\nSet this flag to use plain HTTP requests when accessing a registry. It is supposed to be used for testing purposes only and should not be used in production!\nYou can set it multiple times for multiple registries.\n\n#### --skip-tls-verify-registry\n\nSet this flag to skip TLS certificate validation when accessing a registry. It is supposed to be used for testing purposes only and should not be used in production!\nYou can set it multiple times for multiple registries.\n\n#### --cleanup\n\nSet this flag to clean the filesystem at the end of the build.\n\n#### --insecure\n\nSet 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!\n\n#### --insecure-pull\n\nSet 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!\n\n#### --no-push\n\nSet this flag if you only want to build the image, without pushing to a registry.\n\n#### --registry-mirror\n\nSet this flag if you want to use a registry mirror instead of default `index.docker.io`.\n\n#### --reproducible\n\nSet this flag to strip timestamps out of the built image and make it reproducible.\n\n#### --single-snapshot\n\nThis 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.\n\n#### --skip-tls-verify\n\nSet this flag to skip TLS certificate validation when pushing to a registry. It is supposed to be used for testing purposes only and should not be used in production!\n\n#### --skip-tls-verify-pull\n\nSet this flag to skip TLS certificate validation when pulling from a registry. It is supposed to be used for testing purposes only and should not be used in production!\n\n#### --snapshotMode\n\nYou can set the `--snapshotMode=` flag to set how kaniko will snapshot the filesystem.\nIf `--snapshotMode=time` is set, only file mtime will be considered when snapshotting (see\n[limitations related to mtime](#mtime-and-snapshotting)).\n\n#### --target\n\nSet this flag to indicate which build stage is the target build stage.\n\n#### --tarPath\n\nSet this flag as `--tarPath=` to save the image as a tarball at path instead of pushing the image.\nYou need to set `--destination` as well (for example `--destination=image`).\n\n#### --verbosity\n\nSet this flag as `--verbosity=` to set the logging level. Defaults to `info`.\n\n#### --whitelist-var-run\n\nIgnore /var/run when taking image snapshot. Set it to false to preserve /var/run/* in destination image. (Default true).\n\n#### --label\n\nSet this flag as `--label key=value` to set some metadata to the final image. This is equivalent as using the `LABEL` within the Dockerfile.\n\n### Debug Image\n\nThe kaniko executor image is based on scratch and doesn't contain a shell.\nWe provide `gcr.io/kaniko-project/executor:debug`, a debug image which consists of the kaniko executor image along with a busybox shell to enter.\n\nYou can launch the debug image with a shell entrypoint:\n\n```shell\ndocker run -it --entrypoint=/busybox/sh gcr.io/kaniko-project/executor:debug\n```\n\n## Security\n\nkaniko by itself **does not** make it safe to run untrusted builds inside your cluster, or anywhere else.\n\nkaniko relies on the security features of your container runtime to provide build security.\n\nThe minimum permissions kaniko needs inside your container are governed by a few things:\n\n* The permissions required to unpack your base image into its container\n* The permissions required to execute the RUN commands inside the container\n\nIf you have a minimal base image (SCRATCH or similar) that doesn't require\npermissions to unpack, and your Dockerfile doesn't execute any commands as the\nroot user, you can run Kaniko without root permissions. It should be noted that\nDocker runs as root by default, so you still require (in a sense) privileges to\nuse Kaniko.\n\nYou may be able to achieve the same default seccomp profile that Docker uses in your Pod by setting [seccomp](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#seccomp) profiles with annotations on a [PodSecurityPolicy](https://cloud.google.com/kubernetes-engine/docs/how-to/pod-security-policies) to create or update security policies on your cluster.\n\n## Comparison with Other Tools\n\nSimilar tools include:\n\n- [BuildKit](https://github.com/moby/buildkit)\n- [img](https://github.com/genuinetools/img)\n- [orca-build](https://github.com/cyphar/orca-build)\n- [umoci](https://github.com/openSUSE/umoci)\n- [buildah](https://github.com/containers/buildah)\n- [FTL](https://github.com/GoogleCloudPlatform/runtimes-common/tree/master/ftl)\n- [Bazel rules_docker](https://github.com/bazelbuild/rules_docker)\n\nAll of these tools build container images with different approaches.\n\nBuildKit (and `img`) can perform as a non-root user from within a container but requires\nseccomp and AppArmor to be disabled to create nested containers. `kaniko`\ndoes not actually create nested containers, so it does not require seccomp and AppArmor\nto be disabled.\n\n`orca-build` depends on `runc` to build images from Dockerfiles, which can not\nrun inside a container (for similar reasons to `img` above). `kaniko` doesn't\nuse `runc` so it doesn't require the use of kernel namespacing techniques.\nHowever, `orca-build` does not require Docker or any privileged daemon (so\nbuilds can be done entirely without privilege).\n\n`umoci` works without any privileges, and also has no restrictions on the root\nfilesystem being extracted (though it requires additional handling if your\nfilesystem is sufficiently complicated). However, it has no `Dockerfile`-like\nbuild tooling (it's a slightl","has_starred","hub_user","immutable_tags_settings",{"_75":11,"_76":77},"enabled","rules",[78],".*","is_automated","permissions",{"_82":21,"_83":11,"_84":11},"read","write","admin","user","storage_size",22316595,"orgData","recentTags",[91],{"_92":44,"_93":94,"_95":96,"_97":98,"_99":100,"_50":117,"_118":94,"_119":33,"_120":56,"_57":121,"_122":123,"_124":108,"_125":117,"_126":66,"_127":21},"content_type","creator",353688,"full_size",22310757,"id",93234142,"images",[101],{"_102":103,"_104":105,"_106":48,"_107":108,"_109":110,"_111":112,"_113":48,"_114":-5,"_115":96,"_63":66,"_116":-5},"architecture","amd64","digest","sha256:3e73d6698ccd7bacdd75050f791fee5a71e525c51de6c740a920630f715d8463","features","last_pulled","2026-10-01T19:46:30.786205727Z","last_pushed","2020-03-31T21:23:49Z","os","linux","os_features","os_version","size","variant","2020-04-01T14:40:09.518125Z","last_updater","last_updater_username","media_type","latest","repository",8748518,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"selectedTag","attestationsUrl","routes/_layout.r.$namespace.$reponame.tags",{"_38":141,"_148":149,"_135":158,"_159":11},{"_40":142,"_42":143,"_45":46,"_47":48,"_49":11,"_50":51,"_52":53,"_54":144,"_57":35,"_32":33,"_58":59,"_60":44,"_61":62,"_63":64,"_65":66,"_67":-5,"_68":62,"_69":70,"_71":11,"_72":33,"_73":145,"_79":11,"_80":147,"_85":33,"_86":87},[],[44],[56],{"_75":11,"_76":146},[78],{"_82":21,"_83":11,"_84":11},"tags",{"_150":64,"_151":-5,"_152":-5,"_153":154},"count","next","previous","results",[155],{"_92":44,"_93":94,"_95":96,"_97":98,"_99":156,"_50":117,"_118":94,"_119":33,"_120":56,"_57":121,"_122":123,"_124":108,"_125":117,"_126":66,"_127":21},[157],{"_102":103,"_104":105,"_106":48,"_107":108,"_109":110,"_111":112,"_113":48,"_114":-5,"_115":96,"_63":66,"_116":-5},[],"canDeleteTags","actionData","errors"]

avenda/kaniko

Tags for avenda/kaniko