[{"_1":2,"_165":-5,"_166":-5},"loaderData",{"_3":4,"_13":14,"_21":22,"_140":141},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11,"_20":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_23":24,"_25":-5,"_26":11,"_27":11,"_28":29,"_30":31,"_32":-5,"_33":11,"_34":35,"_85":-5,"_86":87,"_133":-5,"_134":11,"_135":17,"_136":11,"_137":-5,"_138":139},"canonicalUrl","https://hub.docker.com/r/csanchez/kaniko/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","csanchez","reponame","kaniko","cloudBuildSource","isAutobuildsAvailable","repo",{"_36":37,"_38":39,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":51,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":65,"_66":67,"_68":11,"_69":29,"_70":71,"_76":17,"_77":78,"_82":29,"_83":84},"categories",[],"content_types",[40],"image","date_registered","2018-05-17T11:26:31.136206Z","description","Kaniko image for Jenkins","is_private","last_updated","2018-11-02T16:30:06.538554Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[52],"application/vnd.docker.container.image.v1+json","name","pull_count",2555,"repository_type","star_count",6,"status",1,"status_description","active","source","collaborator_count",0,"full_description","# kaniko - Build Images In Kubernetes\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\n\n- [Kaniko](#kaniko)\n - [How does kaniko work?](#how-does-kaniko-work)\n - [Known Issues](#known-issues)\n- [Demo](#demo)\n- [Development](#development)\n - [kaniko Build Contexts](#kaniko-build-contexts)\n - [Running kaniko in a Kubernetes cluster](#running-kaniko-in-a-kubernetes-cluster)\n - [Running kaniko in gVisor](#running-kaniko-in-gvisor)\n - [Running kaniko in Google Container Builder](#running-kaniko-in-google-container-builder)\n - [Running kaniko locally](#running-kaniko-locally)\n - [Pushing to Different Registries](#pushing-to-different-registries)\n - [Debug Image](#debug-image)\n- [Security](#security)\n- [Comparison with Other Tools](#comparison-with-other-tools)\n- [Community](#community)\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\nkaniko does not support building Windows containers.\n\n## Demo\n\n![Demo](/docs/demo.gif)\n\n## Development\n### kaniko Build Contexts\nkaniko supports local directories and GCS buckets as build contexts. To specify a local directory, pass in the `--context` flag as an argument to the executor image.\nTo specify a GCS bucket, pass in the `--bucket` flag.\nThe GCS bucket should contain a compressed tar of the build context called `context.tar.gz`, which kaniko will unpack and use as the build context.\n\nTo create `context.tar.gz`, run the following command:\n```shell\ntar -C -zcvf context.tar.gz .\n```\n\nOr, you can use [skaffold](https://github.com/GoogleContainerTools/skaffold) to create `context.tar.gz` by running\n```\nskaffold docker context\n```\n\nWe can copy over the compressed tar to a GCS bucket with gsutil:\n\n```\ngsutil cp context.tar.gz gs://\n```\n\n### Running kaniko in a Kubernetes cluster\n\nRequirements:\n* Standard Kubernetes cluster\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 the secret, first you will need to create a service account in the Google Cloud Console project you want to push the final image to, with `Storage Admin` permissions.\nYou can download a JSON key for this service account, and rename it `kaniko-secret.json`.\nTo create the secret, run:\n\n```shell\nkubectl create secret generic kaniko-secret --from-file=\n```\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 \"--bucket=\",\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 Container Builder\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=\",\n \"--destination=\"]\n```\nkaniko will build and push the final image in this build step.\n\n### Running kaniko locally\n\nRequirements:\n* Docker\n* gcloud\n\nWe can run the kaniko executor image locally in a Docker daemon to build and push an image from a Dockerfile.\n\nFirst, we want to load the executor image into the Docker daemon by running\n```shell\nmake images\n```\n\nTo run kaniko in Docker, run the following command:\n```shell\n./run_in_docker.sh \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 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 `/root/.docker/config.json`\n\n docker run -ti --rm -v `pwd`:/workspace -v config.json:/root/.docker/config.json:ro gcr.io/kaniko-project/executor:latest --dockerfile=Dockerfile --destination=yourimagename\n\n#### Pushing to Amazon ECR\nThe Amazon ECR [credential helper](https://github.com/awslabs/amazon-ecr-credential-helper) is built in to the kaniko executor image.\nTo configure credentials, you will need to do the following:\n1. Update the `credHelpers` section of [config.json](https://github.com/GoogleContainerTools/kaniko/blob/master/files/config.json) with the specific URI of your ECR registry:\n```json\n{\n\t\"credHelpers\": {\n\t\t\"aws_account_id.dkr.ecr.region.amazonaws.com\": \"ecr-login\"\n\t}\n}\n```\nYou can mount in the new config as a configMap:\n```shell\nkubectl create configmap docker-config --from-file=\n```\n2. Create a Kubernetes secret for your `~/.aws/credentials` file so that credentials can be accessed within the cluster.\nTo create the secret, run:\n\n```shell\nkubectl create secret generic aws-secret --from-file=\n```\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=\",\n \"--destination=\"]\n volumeMounts:\n - name: aws-secret\n mountPath: /root/.aws/\n - name: docker-config\n mountPath: /root/.docker/\n restartPolicy: Never\n volumes:\n - name: aws-secret\n secret:\n secretName: aws-secret\n - name: docker-config\n configMap:\n name: docker-config\n```\n### Debug Image\n\nThe kaniko executor image is based off of 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```shell\ndocker run -it --entrypoint=/busybox/sh gcr.io/kaniko-project/executor:debug\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 it's 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* [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/projectatomic/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\n`img` can perform as a non root user from within a container, but requires that\nthe `img` container has `RawProc` access to create nested containers. `kaniko`\ndoes not actually create nested containers, so it does not require `RawProc`\naccess.\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 slightly lower-level tool that can be used to build such\nbuilders -- such as `orca-build`).\n\n`buildah` requires the same privileges as a Docker daemon does to run, while\n`kaniko` runs without any special privileges or permissions.\n\n`FTL` and `Bazel` aim to achieve the fastest possible creation of Docker images\nfor a subset of images. These can be thought of as a special-case \"fast path\"\nthat can be used in conjunction with the support for general Dockerfiles kaniko\nprovides.\n\n## Community\n\n[kaniko-users](https://groups.google.com/forum/#!forum/kaniko-users) Google group\n","has_starred","hub_user","immutable_tags_settings",{"_72":11,"_73":74},"enabled","rules",[75],".*","is_automated","permissions",{"_79":17,"_80":11,"_81":11},"read","write","admin","user","storage_size",120243762,"orgData","recentTags",[88,125],{"_89":40,"_90":91,"_92":93,"_94":95,"_96":97,"_46":114,"_115":91,"_116":29,"_117":52,"_53":118,"_119":120,"_121":-5,"_122":114,"_123":112,"_124":17},"content_type","creator",18793,"full_size",14968994,"id",38129623,"images",[98],{"_99":100,"_101":102,"_103":104,"_105":-5,"_106":-5,"_107":108,"_109":104,"_110":-5,"_111":93,"_59":112,"_113":-5},"architecture","amd64","digest","sha256:d3e6ad76f0a27a4db37c9093c539c7200946e404319ad47a2d00c55cb354069a","features","","last_pulled","last_pushed","os","linux","os_features","os_version","size","inactive","variant","2018-11-02T16:30:02.710999Z","last_updater","last_updater_username","media_type","test","repository",5509479,"tag_last_pulled","tag_last_pushed","tag_status","v2",{"_89":40,"_90":91,"_92":126,"_94":127,"_96":128,"_46":131,"_115":91,"_116":29,"_117":52,"_53":132,"_119":120,"_121":-5,"_122":131,"_123":112,"_124":17},16705712,27520302,[129],{"_99":100,"_101":130,"_103":104,"_105":-5,"_106":-5,"_107":108,"_109":104,"_110":-5,"_111":126,"_59":112,"_113":-5},"sha256:bb7273cd13499702c93a3a72d54d5850a26c8a13f73a49c12e12b7a5103220e7","2018-06-15T07:06:18.029233Z","jenkins","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_34":142,"_149":150,"_138":163,"_164":11},{"_36":143,"_38":144,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":145,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":65,"_66":67,"_68":11,"_69":29,"_70":146,"_76":17,"_77":148,"_82":29,"_83":84},[],[40],[52],{"_72":11,"_73":147},[75],{"_79":17,"_80":11,"_81":11},"tags",{"_151":152,"_153":-5,"_154":-5,"_155":156},"count",2,"next","previous","results",[157,160],{"_89":40,"_90":91,"_92":93,"_94":95,"_96":158,"_46":114,"_115":91,"_116":29,"_117":52,"_53":118,"_119":120,"_121":-5,"_122":114,"_123":112,"_124":17},[159],{"_99":100,"_101":102,"_103":104,"_105":-5,"_106":-5,"_107":108,"_109":104,"_110":-5,"_111":93,"_59":112,"_113":-5},{"_89":40,"_90":91,"_92":126,"_94":127,"_96":161,"_46":131,"_115":91,"_116":29,"_117":52,"_53":132,"_119":120,"_121":-5,"_122":131,"_123":112,"_124":17},[162],{"_99":100,"_101":130,"_103":104,"_105":-5,"_106":-5,"_107":108,"_109":104,"_110":-5,"_111":126,"_59":112,"_113":-5},[],"canDeleteTags","actionData","errors"]

csanchez/kaniko

Tags for csanchez/kaniko