Falco: Review and Document Dockerfiles

[kris-nova]

Motivation

After mentioning deprecating docker images in #1015 I think this merits a holistic review of our Dockerfiles.

Feature

Can we please audit, and document which container images we are supporting, how each of them should be used, and assign owner(s) for them?

Alternatives

Additional context

[kris-nova]

From @mstemm in Slack :+1:

a tailored build suitable for alpine linux would help a lot with making the container smaller and with a smaller potential set of dependencies. We’d have to build an .apk from source that links against musl libc, but once you had that, creating the image would be as simple as changing the base image to some alpine image and doing an apk add instead of dpkg -i

[kris-nova]

Another quick note, as https://github.com/falcosecurity/falco/issues/1024 starts to ramp up, we in theory should be able to drastically simplify our Dockerfiles

I think in a perfect world all a Falco dockerfile will do is use the in-house package manager to install Falco as it would on any other operating system.

[leodido]

Now that the main docker images have been refactored (PR #1059, #1063, #1069, #1076, etc) let's recap the current situation so to highlight what we still could/should do about them.

| name (falcosecurity:...) | directory | scope | auto build & push |
|---------------------------------------------------------------------------------------------------------|---------------------------|------------------------------------------------------------------------------------|-------------------|
| falco-builder:latest | docker/builder | use it to build Falco (CI) | |
| falco-tester:latest | docker/tester | use it to run Falco integration tests (CI) | |
| to not be published | docker/local | built on-the-fly and used by falco-tester | |
| falco:latest, falco:\falco:master | docker/stable | Falco (DEB built from git tag or from the master) with all the building toolchain | :white_check_mark: |
| falco:latest-minimal, falco:master-minimal | docker/minimal | Falco (TGZ built from git tag or from the master) without the building toolchain | :white_check_mark: |
| falco:latest-slim, falco:master-slim | docker/slim | Falco (DEB build from git tag or from the master) without the building toolchain | :white_check_mark: |
| not able to find where it has been published | docker/rhel | | |
| falco-event-generator:latest | docker/event-generator | Event generator tool to simulate events Falco catches | |
| probe-linuxkit-4.9.184 | docker/kernel/linuxkit | to build and to insert the Falco kernel module on linuxkit kernel 4.19.184 | |
| probeloader:latest | docker/kernel/probeloader | to install the Falco kernel module by the mean of falcoctl install probe command | |

Some considerations:

1. I'd remove the docker/rhel image because:
   1.1 I could not find it published somewhere
   1.2 It's based on rhel7 image and it'd make not straightforward for everyone to build and test locally

2. I'd rename falcosecurity/falco-event-generator into falcosecurity/event-generator, then
   2.1 In case we decide as a community to keep this tool inside the Falco repository we should integrate its build and publish in the new release process (https://github.com/falcosecurity/falco/issues/1089)
   2.2 I'd personally move into in another repository, I'll propose a discussion about this in the next community call

3. I'd remove probe-linuxkit-4.9.184 because:
   3.1 we now have driverkit to build the kernel module for linuxkit

4. I'd remove probeloader because:
   4.1 does not seems to me the community is using it
   4.2 it simply wraps a falcoctl command
   4.3 it would be better to not have the side tooling like this in the Falco repo

5. I think it is correct that falco-builder, falco-tester (and the docker/local image it builds on the fly) are not integrated into the release process because:
   5.1 they are development tools that needs to be manually pushed only when we update them
   5.2 the CI and the release process themselves rely on them to work

[fntlnz]

I agree with everything !! @leodido let's make it happen

[kris-nova]

I agree - like we said in slack I think we need to be aware of what we keep in the repository as we stage for our first LTS release of Falco

Also we mentioned renaming the probeloader on the last call - we should probably consider that as well as here.

Once we label something LTS we have to preserve some sort of backward compatibility (yet to be defined) so if we are deleting images and support - now is the time.

[leodido]

We need to review this page, and maybe merge in it what I wrote two comments above.

After that, and after we remove the unused docker images, I think we'll be able to close this.

[leodido]

FYI @Issif

[leogr]

I totally agree too. Furthermore, probeloader:latest might not work anymore because of falcoctl, and here we are discussing what falcoctl will do.
I will take care of fixing this asap
/assign