[Sandbox] Kaniko

[aaron-prindle]

Application contact emails

aprindle@google.com

Project Summary

Daemonless, easy and secure Dockerfile container builds on Kubernetes

Project Description

Kaniko is a tool designed to build container images from a Dockerfile, inside a container or Kubernetes cluster. It does this without requiring a Docker daemon, making it a safer and more efficient way to build images compared to Docker-in-Docker (DinD) alternatives, especially in cloud-native environments. Kaniko solves the security concerns associated with the traditional DinD image building process (and other nested container approaches directly requiring namespaces & cgroups access), as it doesn’t require privileged root access on the host machine. This allows it to be used across more environments and run with additional sandboxing that can be incompatible with common container build methods. This aligns with the best practices for building secure and portable cloud-native applications, enabling developers to build images in any environment including Kubernetes clusters.

Since its inception as a tool to help Kubernetes CI/CD use cases, it has since broken out and become used by and supported by companies and projects for building on-cluser, including Gitlab, CloudBees, Tekton, and Devspace. It is directly integrated into Kubeflow for building container images. It boasts 13600+ GitHub stars, and doesn't show any signs of slowing down.

Org repo URL (provide if all repos under the org are in scope of the application)

N/A

Project repo URL in scope of application

https://github.com/GoogleContainerTools/kaniko

Additional repos in scope of the application

No response

Website URL

https://github.com/GoogleContainerTools/kaniko

Roadmap

https://github.com/GoogleContainerTools/kaniko/blob/main/ROADMAP.md

Roadmap context

No response

Contributing Guide

https://github.com/GoogleContainerTools/kaniko/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/GoogleContainerTools/kaniko/blob/main/code-of-conduct.md

Adopters

No response

Contributing or Sponsoring Org

Google - https://github.com/GoogleContainerTools

Maintainers file

https://github.com/GoogleContainerTools/kaniko/blob/main/MAINTAINERS.md

IP Policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

Why CNCF?

Kaniko has garnered attention and adoption through organic growth, primarily driven by its innovative approach to container image building. Despite its successes, its association as a "Google tool" limits its potential contributor base. In reality, the project is very independently maintained, by maintainers and contributors inside and outside of Google. Its roadmap is decided by these maintainers, not by any Google strategy.

By joining the CNCF, we aim to elevate Kaniko's visibility and underscore its independence, encouraging broader adoption and contribution from the cloud-native community. The CNCF's resources and network will be instrumental in scaling Kaniko's impact, fostering integrations with other projects, and facilitating its growth as a community-driven project.

Benefit to the Landscape

Kaniko is designed around a novel approach to building container images from Dockerfiles securely and efficiently in Kubernetes environments. This enhances the CNCF landscape by offering a tool that aligns with cloud-native principles and complements existing container management and orchestration tools.

Additionally CNCF's landscape currently doesn't have many build tools. Buildpacks and ko are the main solutions here which don't support Dockerfile builds which many in the ecosystem rely on. Having more diverse tools like this can give end users more diverse options when looking for a solution.

Cloud Native 'Fit'

Kaniko epitomizes the cloud-native ethos by enabling container image builds in a Kubernetes-native way. It leverages the existing infrastructure and workflows of CNCF users/projects, aligning with the cloud-native philosophy of scalability, security, and portability. Kaniko lets users treat building containers as just another process in their Kubernetes cluster, not having to do any special plumbing or wiring up of permissions to get it working.

Cloud Native 'Integration'

Kaniko complements various CNCF projects like Kubernetes, Kubeflow, ArgoCD, and GitLab by providing a seamless and secure way to build container images for CI/CD and container orchestration platforms. Kaniko allows these projects to build containers from Dockerfiles (the most widely used container DSL) in an easy and secure way not possible with alternatives which is the project has grown and is incorporated by users on these platforms today. Kubeflow directly integrates with Kaniko for building container images on cluster

Cloud Native Overlap

Kaniko overlaps with projects like Buildpacks and Docker in the container image creation space but offers a unique approach by eliminating the need for a Docker daemon while still supporting Dockerfiles. Kaniko's approach of building containers without relying on namespaces & cgroups directly but assuming a containerized environment is unique and gives it UX and security advantages over other alternatives.

Similar projects

Outside of CNCF, the whale in the room is obviously docker build, which is very widely used, and its ease of use has been pivotal in the rise of containers across the Cloud Native ecosystem.

As with Buildpacks, kaniko uses different architectural design to docker build, and as such can optimize things much better for exactly the use case it aims to solve. So many Cloud Native projects and applications run on Kubernetes, and could benefit from being able to build images easily on cluster (via kaniko UX) as well as building images more securely.

Landscape

Yes - https://landscape.cncf.io/?item=app-definition-and-development--application-definition-image-build--kaniko

Business Product or Service to Project separation

N/A

Project presentations

N/A

Project champions

No response

Additional information

No response

[angellk]

@amye could you please add the TAG Runtime label (in addition to TAG App Delivery)?

[aaron-prindle]

Hi @angellk and @amye, currently this application is a part of the next batch of CNCF Sandbox Application Reviews which is slated for April 9th (https://github.com/orgs/cncf/projects/14). I just wanted to confirm if there was anything additional that should be done for Kaniko prior-to/during-this CNCF Sandbox Application review? Want to make sure we have done everything necessary for the process. Currently my understanding is that there is nothing else to do, just want to confirm - thanks!

[dims]

@aaron-prindle activity seems to be dropping off https://github.com/GoogleContainerTools/kaniko/graphs/contributors?from=2023-07-19&to=2024-07-23&type=c is there going to be continuing interest/investment to help the massive set of end users who depend on it? (given the usage/stars etc)

[aaron-prindle]

Hi @dims!

activity seems to be dropping off https://github.com/GoogleContainerTools/kaniko/graphs/contributors?from=2023-07-19&to=2024-07-23&type=c

Can you explain the rationale for activity seems to be dropping off? Currently the GoogleContainerTools/kaniko project is staffed with maintainers, doing regular project releases, reviewing and merging community contributed PRs, and responding to + triaging inbound Github issues. Activity on the project in 2024 is line with or above 2023, 2022, and 2021 so trying to understand what the dropoff is referring to?

• 2024 (halfway) : ~9 contributors so far
• 2023: ~19 contributors
• 2022: ~18 contributors
• 2021: ~11 contributors

NOTE: these are for the merged PRs vs inbound PRs which would have more contributors as not all are accepted

The numbers there seem comparable to other projects that were accepted to the CNCF IIUC from a cursory glance although I might be missing some specific metrics related to activity or contributors.

is there going to be continuing interest/investment to help the massive set of end users who depend on it? (given the usage/stars etc)

Yes, there is going to be continued interest/investment in GoogleContainerTools/kaniko to help the massive set of end users who depend on it.

[srust]

Hi @aaron-prindle! As part of the TAG-Runtime review, do you have a recent presentation (slides) you or the project team has done talking about the project, history, community, roadmap, etc. ? This would be very helpful as a summary as we do our research, if you do have one. Something that if you were to present to a TAG about the project you would be able to talk to and use. Also, do you have a recent demo video? The one linked on your github is 3 years old. Thanks!

[srust]

@aaron-prindle We have the following additional questions for the project team. Thank you in advance!

• Describe the roadmap process, how scope is determined for mid to long term features, as well as how the roadmap maps back to current contributions and maintainer ladder?
• Any dependencies on kubernetes versions, or the need to stay up to date with kubernetes changes?
• How are breaking changes in releases communicated?
• What is the project intending to continue growth? How does the project plan to expand participation from different companies and organizations?
• Please provide a link to the project’s cloud native security self assessment.
  ** If one has not been done, while not required, this is highly recommended

[srust]

Kaniko Sandbox Review

Date	Aug 6, 2024
Project Name	Kaniko
TAG	TAG Runtime
Presentation	No
Project Leads Presenting	N/A
TAG Leadership Reviewers	Stephen Rust

Video and Demo:

https://www.youtube.com/watch?v=EgwVQN6GNJg
https://github.com/GoogleContainerTools/kaniko/blob/45a6d2db9fc4338877063ed7d7de71ee242bf151/docs/demo.gif

Project Information

High-level Summary

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

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.

TAG and Working Group Alignment

This is a general TAG-Runtime and TAG-App Delivery project, no specific working group alignment.

History

Kaniko’s first release was May 17, 2018. Kaniko has 14.4k stars on github and 1.4k forks.

Architecture

kaniko is meant to be run as an image: gcr.io/kaniko-project/executor. It is primarily written in GO. It can run standalone, but is designed to be run within Kubernetes as a pod. Specify a service account, and create a pod spec to run the kaniko builder. The interface and UX is through running the image and specifying command line arguments, for example in a Pod spec.

Example Execution:

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

Goals & Roadmap

Roadmap was added in February 2024:
https://github.com/GoogleContainerTools/kaniko/blob/main/ROADMAP.md

Key Considerations:

Community and Growth

The current list of maintainers shows 3 all from google. There are ~18 contributors per year of contributors doing at least 1 commit.

Security issues are handled through a documented intake process.

Kaniko slack channel is fairly low volume with low interaction: https://app.slack.com/client/T09NY5SBT/CQDCHGX7Y

There are 653 open issues (oldest 2018).

There are 27 open pull requests (oldest 2023).

Requires Google CLA in order to contribute.

As there is one primary vendor in a vendor provided repo, if that vendor were to step away the project would likely have trouble continuing.

Release Process, Issues and Testing Infrastructure

• 60 releases, with releases occurring regularly. Latest last month.
• Tests are run through GHA on github infra
• amd64 only
• Depends on Google code project `container-diff` for integration testing

Project Challenges

• The current set of maintainers is google only
• The kaniko release process requires a google employee to do an official release
• Keeping up to date with Dockerfile changes and compatibility is always a moving target and maintenance burden. Users in the project issues discuss incompatibility with new arguments added to the Dockerfile syntax through history (e.g. add –chown option to ADD). This will be a challenge and expectation of the project to keep up to date.

Key Feedback to the Project:

• We recommend moving kaniko to a non-google community github organization
• Maintainer diversity is important, adding non-google maintainer(s) is recommended
• Enable non-google employees to perform official releases
• As a dependency, suggest moving `container-diff` tool also to a non-google community github organization for longevity of dependencies
• Suggest identifying previous maintainers as “emeritus” in the repo

TAG Recommendation to TOC:

Kaniko has a long 6+ year history as a rootless, secure, container build tool. There are concerns about maintainer diversity (currently single vendor), and the ability for the community to perform releases without a vendor. Maintenance burden for Dockerfile syntax changes, security issues, and version compatibility is consistent but not unusual. We are looking forward to the project’s response to our previous questions, and addressing the key feedback above, and would recommend moving forward with the sandbox application given those responses.

[jberkus]

TAG Contributor strategy has reviewed this project and found the following:

• The contributor guide is basic.
• There is no documented project governance yet
• The roadmap is a new document which covers the high-level development goals for each half-year
• There are three maintainers, who work for Google
• The project has had 297 contributors, some of whom do not work at Google

This review is for the TOC’s information only. Sandbox projects are not required to have full governance or contributor documentation.

[angellk]

@aaron-prindle
Thank you so much for your application to the CNCF, at this time the TOC will not be moving the Kaniko Sandbox application to a vote.

We would like to see this project apply at Incubation level with:

• a robust, documented project governance
• increased maintainer diversity