From 695594b42ce7ab7af672ce32e688d9fedbc52dcb Mon Sep 17 00:00:00 2001 From: Vadim Bauer Date: Wed, 7 Feb 2024 16:40:00 +0100 Subject: [PATCH 1/2] propose to switch so scratch images. --- proposals/switch-to-scratch-images.md | 101 ++++++++++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 proposals/switch-to-scratch-images.md diff --git a/proposals/switch-to-scratch-images.md b/proposals/switch-to-scratch-images.md new file mode 100644 index 00000000..ecfc512c --- /dev/null +++ b/proposals/switch-to-scratch-images.md @@ -0,0 +1,101 @@ +# Harbor Community Proposal - We should build all Harbor Images based Scratch + +Status: In Progress +Created by: Vadim Bauer +Created time: February 07, 2024 1:17 PM +Last Edited: February 07, 2024 1:52 PM + +# **Proposal: Scratch Images** + +# **Abstract** + + +https://hub.docker.com/_/scratch/ + +This proposal advocates switching to use Scratch images for Harbor. +This approach reduces container size, enhances security, and optimizes resource utilization. +It streamlines the deployment process, reducing image footprint and accelerating application startup. +Utilizing Scratch images leads to a more agile development cycle and improved scalability. + +Using Scratch images aligns with Golang's philosophy of simplicity and performance, +creating a streamlined and resource-efficient containerized environment for Golang applications. + +# **Background** + +Today Harbor is using PhotonOS base images. On top of the base image that already +comes with many unnecessary dependencies, we are installing addition tools that +increase the potential attack surface even further. + +The consequence is that the project received regular vulnerability reports that +primary affect those dependencies. +Most of the older images don't receive vulnerability patches. + +PhotonOS base image patching can be also delayed by weeks and months, making the process unnecessary slow. + +# **Proposal** +The proposal is replacing as many base images with scratch as possible. +Images where it would make sense can be migrated to distroless, or remain Photon based. + + +# **Benefits for Harbor and the Ecosystem** + +* Reduced Image sizes result in faster turnaround time while developing and distributing software. +* Good for the environment; as less power, storge is used in transfer and storage +* Attack surface of the core applications is drastically reduced. +* Less maintenance and patching +* Faster build for local development +* Easier to support Arm or any other infrastructure + + +# **Non-Goals** + +Replace all images with distroless or scratch. While this would be definitely a +great achievement the easier part would be to replace what is currently possible. + + +## Rationale + +Scratch is the most stripped down version of a Docker container. +Scratch contains nothing in it except for the executable binary which you add to it. +It has no shell, nothing extra. + +An Alternative To Scratch +A distroless image is not a single image to solve the problem, like scratch is. +Instead, distroless images are a class of minimal images which contain only your +application and the application’s runtime dependencies. + +The static distroless image, gcr.io/distroless/static, is the simplest of all the distroless images. +It contains a minimal Linux, glibc-based system with: + +📝 ca-certificates +🔒 A /etc/passwd entry for a root user +🗑️ A /tmp directory +⌚ tzdata + +Currently there are two major distroless streams google and Wolfi. +The second one has a commercial purpose only, and can't be used in the Open Source Context + + +[A discussion of alternate approaches and the trade offs, advantages, and disadvantages of the specified approach.] + +## Compatibility + +Downsides of Scratch, is that they only work for compiled languages, and debugging +only works with a debug container or pod. +There are already many elaborated solutions for [debugging container in Docker](https://docs.docker.com/engine/reference/commandline/debug/) and [Kubernetes](https://kubernetes.io/docs/tasks/debug/debug-cluster/kubectl-node-debug/) + + +## Implementation + +In the first phase, we would focus on the migration of the core application like +core, registry, exporter, jobservice, registryctl, trivy-adapter + +## Open issues (if applicable) + +As mentioned, the only open issue if scratch can be used only applies to: + +* Nginx (portal) +* Postgres (db) +* Redis (cache) + +In the given cases we can evaluate and test if From e5c1f745555285d849476615a3b0c0fc84b88547 Mon Sep 17 00:00:00 2001 From: Vadim Bauer <1492007+Vad1mo@users.noreply.github.com> Date: Tue, 11 Jun 2024 10:09:17 +0200 Subject: [PATCH 2/2] no message Signed-off-by: Vadim Bauer <1492007+Vad1mo@users.noreply.github.com> --- proposals/switch-to-scratch-images.md | 96 +++++++++++++++++---------- 1 file changed, 60 insertions(+), 36 deletions(-) diff --git a/proposals/switch-to-scratch-images.md b/proposals/switch-to-scratch-images.md index ecfc512c..87143b1d 100644 --- a/proposals/switch-to-scratch-images.md +++ b/proposals/switch-to-scratch-images.md @@ -9,62 +9,72 @@ Last Edited: February 07, 2024 1:52 PM # **Abstract** - https://hub.docker.com/_/scratch/ -This proposal advocates switching to use Scratch images for Harbor. -This approach reduces container size, enhances security, and optimizes resource utilization. -It streamlines the deployment process, reducing image footprint and accelerating application startup. -Utilizing Scratch images leads to a more agile development cycle and improved scalability. +This proposal advocates switching to use Scratch images for Harbor. +This approach reduces container size, enhances security, and optimizes resource +utilization. +It streamlines the deployment process, reducing image footprint and accelerating +application startup. +Utilizing Scratch images leads to a more agile development cycle and improved +scalability. -Using Scratch images aligns with Golang's philosophy of simplicity and performance, -creating a streamlined and resource-efficient containerized environment for Golang applications. +Using Scratch images aligns with Golang's philosophy of simplicity and +performance, +creating a streamlined and resource-efficient containerized environment for +Golang applications. # **Background** -Today Harbor is using PhotonOS base images. On top of the base image that already -comes with many unnecessary dependencies, we are installing addition tools that +Today Harbor is using PhotonOS base images. On top of the base image that +already +comes with many unnecessary dependencies, we are installing addition tools that increase the potential attack surface even further. -The consequence is that the project received regular vulnerability reports that -primary affect those dependencies. +The consequence is that the project received regular vulnerability reports that +primary affect those dependencies. Most of the older images don't receive vulnerability patches. -PhotonOS base image patching can be also delayed by weeks and months, making the process unnecessary slow. +PhotonOS base image patching can be also delayed by weeks and months, making the +process unnecessary slow. # **Proposal** -The proposal is replacing as many base images with scratch as possible. -Images where it would make sense can be migrated to distroless, or remain Photon based. +The proposal is replacing as many base images with scratch as possible. +Images where it would make sense can be migrated to distroless, or remain Photon +based. # **Benefits for Harbor and the Ecosystem** -* Reduced Image sizes result in faster turnaround time while developing and distributing software. -* Good for the environment; as less power, storge is used in transfer and storage -* Attack surface of the core applications is drastically reduced. +* Reduced Image sizes result in faster turnaround time while developing and + distributing software. +* Good for the environment; as less power, storge is used in transfer and + storage +* Attack surface of the core applications is drastically reduced. * Less maintenance and patching * Faster build for local development -* Easier to support Arm or any other infrastructure - +* Easier to support Arm or any other infrastructure # **Non-Goals** -Replace all images with distroless or scratch. While this would be definitely a -great achievement the easier part would be to replace what is currently possible. - +Replace all images with distroless or scratch. While this would be definitely a +great achievement, the easier part would be to replace what is currently +possible. ## Rationale -Scratch is the most stripped down version of a Docker container. -Scratch contains nothing in it except for the executable binary which you add to it. +Scratch is the most stripped down version of a Docker container. +Scratch contains nothing in it except for the executable binary which you add to +it. It has no shell, nothing extra. An Alternative To Scratch -A distroless image is not a single image to solve the problem, like scratch is. -Instead, distroless images are a class of minimal images which contain only your +A distroless image is not a single image to solve the problem, like scratch is. +Instead, distroless images are a class of minimal images which contain only your application and the application’s runtime dependencies. -The static distroless image, gcr.io/distroless/static, is the simplest of all the distroless images. +The static distroless image, gcr.io/distroless/static, is the simplest of all +the distroless images. It contains a minimal Linux, glibc-based system with: 📝 ca-certificates @@ -72,27 +82,41 @@ It contains a minimal Linux, glibc-based system with: 🗑️ A /tmp directory ⌚ tzdata -Currently there are two major distroless streams google and Wolfi. -The second one has a commercial purpose only, and can't be used in the Open Source Context - +Currently there are two major distroless streams google and Wolfi. +The second one has a commercial purpose only, and can't be used in the Open +Source Context [A discussion of alternate approaches and the trade offs, advantages, and disadvantages of the specified approach.] ## Compatibility -Downsides of Scratch, is that they only work for compiled languages, and debugging -only works with a debug container or pod. -There are already many elaborated solutions for [debugging container in Docker](https://docs.docker.com/engine/reference/commandline/debug/) and [Kubernetes](https://kubernetes.io/docs/tasks/debug/debug-cluster/kubectl-node-debug/) +Downsides of Scratch, is that they only work for compiled languages, and +debugging only works with a debug container or pod. +There are already many elaborated solutions +for [debugging container in Docker](https://docs.docker.com/engine/reference/commandline/debug/) +and [Kubernetes](https://kubernetes.io/docs/tasks/debug/debug-cluster/kubectl-node-debug/) ## Implementation -In the first phase, we would focus on the migration of the core application like -core, registry, exporter, jobservice, registryctl, trivy-adapter +In the first phase, we would focus on the migration of the core application like +core, registry, exporter, jobservice, registryctl, trivy-adapter. + +### Building from scratch: What does It mean? + +“From scratch” means building an image with the “FROM scratch” reference in the +Dockerfile. +So, instead of using commonly used base images like Alpine or Ubuntu or +PhotonOS, in our case, we will reference Scratch. + +This reference creates the smallest possible image, to be precise, it is empty, +containing no files or folders. + +https://medium.com/@m0v_3r/building-container-images-from-scratch-with-the-scratch-base-image-8ff56812124b ## Open issues (if applicable) -As mentioned, the only open issue if scratch can be used only applies to: +As mentioned, the only open issue if scratch can be used only applies to: * Nginx (portal) * Postgres (db)