[falco/image]: falco errors when using "falcosecurity/falco" image

[alacuku]

Describe the bug The falcosecurity organizaton provides two different image flavours for Falco:

• falcosecurity/falco-driver-loader
• falcosecurity/falco For more info: https://falco.org/docs/getting-started/download/#images.

Starting from version 2.0.0 of the charts the falcosecurity/falco-no-driver is the default image. As far as I know, we are still supporting the falcosecurity/falco image in our charts.

With the latest charts, v2.2.0, I get errors when using the falcosecurity/falco image.

In the first case, using the default values of the chart and just setting the falcosecurity/falco image:

helm install falco \
    --set image.repository=falcosecurity/falco \
    falcosecurity/falco

We have both the variables driver.loader.enabled and driver.loader.initContainer.enabled set to true. The init container correctly downloads/builds the kernel module for our system but the falco-driver-loader script runs inside the Falco container and fails with:

* Looking for a Falco module locally (kernel 5.4.0-113-generic)
Detected an unsupported target system, please get in touch with the Falco community

That happens because we are not mounting the /etc/ folder in the Falco container causing the script to fail. And it's ok because we are using the init container: https://github.com/falcosecurity/charts/blob/06225b85abae5beb77e1a11cf0d393a8b1bb8ce8/falco/templates/pod-template.tpl#L133-L146

In the second case, we set to false both driver.loader.enabled and driver.loader.initContainer.enabled:

helm install falco \
    --set image.repository=falcosecurity/falco \
    --set driver.loader.enabled=false \
    --set driver.loader.initContainer.enabled=false \
    falcosecurity/falco

The Falco pods does not start, and the error is:

  Warning  Failed     3s                kubelet            Error: failed to generate container "f41374f044c4a77e9a052ce42445fe1b0a962e3fbde6ae25e32b49e970734b04" spec: failed to generate spec: failed to mkdir "/sys/module/falco": mkdir /sys/module/falco: operation not permitted

In the latest version of the chart we add a new volume mount: /sys/module/falco. For more info why it is needed see here: https://github.com/falcosecurity/falco/pull/2214. The /sys/module/falco folder is available only after the kernel module has been loaded.

In the third case, we set driver.loader.enabled to true but disable the initContainer:

helm install falco \
    --set image.repository=falcosecurity/falco \
    --set driver.loader.enabled=true \
    --set driver.loader.initContainer.enabled=false \
    falcosecurity/falco

We are removing the initContainer, but the logic of the falco-driver-loader script inside the Falco container should be triggered. We still get the error:

  Warning  Failed     4s                kubelet            Error: failed to generate container "f41374f044c4a77e9a052ce42445fe1b0a962e3fbde6ae25e32b49e970734b04" spec: failed to generate spec: failed to mkdir "/sys/module/falco": mkdir /sys/module/falco: operation not permitted

In order to resolve the mount issue without an init container we should mount the whole /sys/module folder inside the Falco container. And that is not a best practice since it is mounted in ReadWrite mode.

How to reproduce it Follow the steps described above. Expected behaviour The Falco pods should be up and running after the deployment.

[alacuku]

I think that we should use always the approach with init-container with the helm charts and deprecate the usage of the falcosecurity/falco image. It would make it easy to simplify the init-container logic as described in: #418.

[alacuku]

cc @leogr

[leogr]

In the third case, we set driver.loader.enabled to true but disable the initContainer:

helm install falco \
    --set image.repository=falcosecurity/falco \
    --set driver.loader.enabled=true \
    --set driver.loader.initContainer.enabled=false \
    falcosecurity/falco

We are removing the initContainer, but the logic of the falco-driver-loader script inside the Falco container should be triggered. We still get the error:

  Warning  Failed     4s                kubelet            Error: failed to generate container "f41374f044c4a77e9a052ce42445fe1b0a962e3fbde6ae25e32b49e970734b04" spec: failed to generate spec: failed to mkdir "/sys/module/falco": mkdir /sys/module/falco: operation not permitted

In order to resolve the mount issue without an init container we should mount the whole /sys/module folder inside the Falco container. And that is not a best practice since it is mounted in ReadWrite mode.

I totally agree it's not a best practice, but not supporting it could break legacy use cases. I'm not completely contrary to getting rid of the third case, but - before removing it - we should make sure nobody needs it anymore.

N.B. I know it does not work with the latest chart version, but it worked with the 2.0.0 AFAIK.

cc @falcosecurity/core-maintainers wdyt?

[Andreagit97]

I agree with @alacuku, using just one approach (the init container one) would be easier for everyone, for us to maintain and for the user to avoid complexity! Moreover, actually, the falcosecurity/falco image is not working due to the mount issue described above so probably nobody is using it or needs it :thinking: It could be the right moment to remove it

[Andreagit97]

If we remove the falcosecurity/falco image we could remove also this block since drivers always need the falco-driver-loader to be installed https://github.com/falcosecurity/charts/blob/06225b85abae5beb77e1a11cf0d393a8b1bb8ce8/falco/templates/pod-template.tpl#L133-L146