[Proposal] Streamlining docker images

[leogr]

Motivation

The modern eBPF probe is gaining prominence, prompting our decision to adopt it as the default driver. This shift offers significant advantages to our distribution system. By moving to the eBPF probe, we eliminate the need to include the full driver-building toolchain in the default Falco distribution. Users who prefer alternative setups can still opt for a different container image. Consequently, this allows us to transition the Falco default image to a "no-driver"/"distroless" configuration, streamlining our deployment and enhancing system simplicity.

As a result of this decision, we have re-audited all Docker images, gathered feedback, and are now proposing to streamline the Falco Docker images to better meet current needs and enhance their functionality. This proposal outlines the desired state of these improvements.

Feature

New supported images

Image Name	Tag (aliases)	Description
falcosecurity/falco	x.y.z (latest)	Distroless image without driver building toolchain support, based on the latest released tar.gz of Falco. No tools or falcoctl not included.
falcosecurity/falco	x.y.z-debian (latest-debian)	Debian-based image without driver building toolchain support, based on the latest released Deb of Falco (similar to the old falcosecurity/falco-no-driver image). May include some tools (ie. jq, curl), but not falcoctl.
falcosecurity/falco-driver-loader	x.y.z (latest)	Based on falcosecurity/falco:x.y.z-debian (see above) plus the driver building toolchain support and also shipping the latest version of falcoctl. Recommended only when modern eBPF is not supported.
falcosecurity/falco-driver-loader	x.y.z-buster (latest)	Similar to falcosecurity/falco-driver-loader (see above) but based on a legacy Debian image (i.e. buster ). Recommended only for old kernel versions

Deprecated images

Image Name	Reason
falcosecurity/falco-distroless	Deprecated in favor of falcosecurity/falco:x.y.z
falcosecurity/falco-no-driver	Deprecated in favor of falcosecurity/falco:x.y.z-debian (basically the same image with a new name)

Other legacy or almost not-used images included in https://hub.docker.com/u/falcosecurity may be deprecated, too.

Alternatives

We have already evaluated different alternatives, but no valid alternatives emerged (or were discarded early).
A still valid alternative would be not to implement some image variants (i.e., -debian and -buster) or add others variants. This, however, may reduce the Falco compatibility range.

Additional context

This needs to be shipped before Falco 1.0 as per our roadmap.

Tentatively for
/milestone 0.38.0

Probably for 0.39.0

[killerkenobi]

I think providing an image that does not include Falcoctl would be a good idea especially for folks trying to run Falco in a more secure environment or that are concerned about attack surface. I created a PR to create a distroless Dockerfile that does not include falcoctl. I have been testing this image in a dev environment with great results over the past week.

I was motivated to modify the existing distroless image as I was seeing several vulnerabilities introduced by falcoctl. I am also running falco in a way that does not require I ever interact with falcoctl. Not sure if anyone else has a similar use case but either way maybe this PR can help them out.

[leogr]

Hey @killerkenobi

as per my proposal, the new falcosecurity/falco will be distroless and not include falcoctl 👇

Distroless image without driver building toolchain support, based on the latest released tar.gz of Falco. No tools or falcoctl not included.

Also, please share 👇 your use case 👇 anyway, it may be useful for someone! 🙏

am also running falco in a way that does not require I ever interact with falcoctl. Not sure if anyone else has a similar use case but either way maybe this PR can help them out.

[killerkenobi]

@leogr that's great to hear and will be very helpful. I am currently running my modified distroless falco image in a Kubernetes environment that restricts access to the internet so Falcoctl would not be allowed to call out and get rule updates. The environment is pretty locked down due to compliance requirements. I am also using a custom rule set that is tailor made for my environment so I have no need to update the Falco-provided rule sets using Falcoctl.

In addition, I have to build my custom falco image using a CI/CD pipeline with strict vulnerability scanning requirements. Falcoctl was constantly failing this pipeline with vulnerabilities in various Go packages. Once I removed Falcoctl the image has been building and working as expected. The distroless image without falcoctl is also only ~50MB where the upstream falco distroless image is ~110MB if I remember correctly.

[leogr]

cc @falcosecurity/falcoctl-maintainers for visibility

[leogr]

/assign
/assign @FedeDP
/assign @LucaGuerra

[LucaGuerra]

While we want to make our images simpler, we will address this in the version after the one we're preparing now, so I'm bumping the milestone.

/milestone 0.39.0

[FedeDP]

I wanted also to highlight that we might want to ship multiple versions of the falco-driver-loader image (ie: the one with the toolchains), because eg: right now ubuntu24.04 ships a glibc version of 2.38 while our falco-driver-loader master image ships with 2.36. This breaks the kmod and bpf drivers build on it.
While this is not a major disruption since on newer kernels we will default at the modern-bpf probe, i think that we should still ship different versions of the falco-driver-loader image:

• falco-driver-loader:x.y.z-buster
• falco-driver-loader:x.y.z-bookworm
• falco-driver-loader:x.y.z-trixie (ie: current debian testing based)

Debian trixie ships with correct glibc version:

/lib/x86_64-linux-gnu/libc.so.6 
GNU C Library (Debian GLIBC 2.38-10) stable release version 2.38.

And so on, as new debian versions come out.

[leogr]

I wanted also to highlight that we might want to ship multiple versions of the falco-driver-loader image (ie: the one with the toolchains), because eg: right now ubuntu24.04 ships a glibc version of 2.38 while our falco-driver-loader master image ships with 2.36. This breaks the kmod and bpf drivers build on it. While this is not a major disruption since on newer kernels we will default at the modern-bpf probe, i think that we should still ship different versions of the falco-driver-loader image:

• falco-driver-loader:x.y.z-buster
• falco-driver-loader:x.y.z-bookworm
• falco-driver-loader:x.y.z-trixie (ie: current debian testing based)

Debian trixie ships with correct glibc version:

/lib/x86_64-linux-gnu/libc.so.6 
GNU C Library (Debian GLIBC 2.38-10) stable release version 2.38.

And so on, as new debian versions come out.

I totally agree. I guess it wouldn't be hard to maintain these variants, and they are useful also for testing purposes.

[FedeDP]

Do we also want to deprecate the slim image?

[leogr]

Do we also want to deprecate the slim image?

Yes, IMO.

The slim is just an alias to the falco-driver-loader image, so we should just use it instead.

falco/.github/workflows/reusable_publish_docker.yaml

Lines 92 to 94 in 0bf7458

	- name: Tag slim manifest on Docker Hub
	run: |
	crane copy docker.io/falcosecurity/falco-no-driver:${{ inputs.tag }} docker.io/falcosecurity/falco:${{ inputs.tag }}-slim

[FedeDP]

I know :) we should add it in the OP for this issue then.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[Andreagit97]

/remove-lifecycle stale

[leogr]

As discussed with @FedeDP we are moving this for
/milestone 0.40

In order to have more time to test and enhance the current WIP implementation.

[poiana]

@leogr: The provided milestone is not valid for this repository. Milestones in this repository: [0.39.0, 0.40.0, 1.0.0, TBD]

Use /milestone clear to clear the milestone.

In response to this:

As discussed with @FedeDP we are moving this for
/milestone 0.40

In order to have more time to test and enhance the current WIP implementation.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[leogr]

/milestone 0.40.0