Make use of distroless image building

[cforce]

Still try to locate the source of the base image stacks and buildpacks are setup on (still looks like fulk blown Ubuntu trusty). I would appreciate to make use of distroless (how low can you go) base and only pull in necessary stuff needed for the specific target runtime.
You may check https://github.com/GoogleContainerTools/distroless

[sclevine]

The default stack uses ubuntu:bionic, which is 32mb.
Here's the base: https://github.com/buildpack/lifecycle/blob/master/Dockerfile
And here are the final images: https://github.com/buildpack/lifecycle/tree/master/images

We're currently adding support for user-provided stacks (#33, #34, #36, #37, #38), and it wouldn't be difficult to create distroless stacks for each runtime that only work with a small subset of buildpacks.

That said, this would remove much of the operational value that buildpacks provide. We use base images that receive ABI-compatible security patches from OS vendors so that those bottom-most image layers can safely be swapped out without rebuilding (or even re-testing) the final image. The advantage to this is that you can patch critical CVEs in an OS package dependencies (like OpenSSL) for thousands of apps without waiting for thousands of pipelines to finish. This a current feature of Cloud Foundry and Heroku that is often overlooked.

For more info, see the buildpack spec and platform spec. The CNB model uses cross repository blob mounting and content addressable layers in the OCI image format to swap the base images out entirely on the registry, with just metadata changes and no data transfer or rebuilding. This means we can patch thousands of apps in a short period of time with no infrastructure costs.

[cforce]

Thanks a lot for that insight. The swapping of CVE patched base images you describe seems to cover what was behind my intension to use distoless images. Even if there is custom need we could use the user provided stack, so my requirement looks as covered with that feature.
Are you also adding support to execute the build pack lifecycle on the Xaas plattform, e.g. like kaniko supports. Making sure that images are assembled in a "safe" environment is another aspect of security we have in mind.

[sclevine]

Are you also adding support to execute the build pack lifecycle on the Xaas plattform, e.g. like kaniko supports

Definitely! Unlike with Dockerfiles, the entire process executes using non-root users in unprivileged containers with a series of pre-determined images. In addition, registry credentials are never present in the same containers that buildpack or app code executes, making the process suitable for multi-tenant platforms.

We've contributed to knative build to ensure compatibility, and we currently have knative/build-templates#67 open to add CNB as an available template. We may also integrate knative template support into the pack CLI directly.

It's also possible to use CNB images with Concourse CI as task base images, but we don't have examples of this published yet.

[cforce]

Great. Already playing with knative ;)