Deprecate Falco's chart integrations in favor of falcosidekick

[leogr]

Motivation

Falco's chart comes with various thirdy-party integrations that seems to be not maintained anymore.

Moreover, the current implementation of those integrations relies on several docker images that live outside the falcosecurity org:

charts/falco/templates/daemonset.yaml

Line 147 in 524dcbc

image: sysdig/falco-nats:latest

,

charts/falco/templates/daemonset.yaml

Line 156 in 524dcbc

image: sysdig/falco-sns:latest

,

charts/falco/templates/daemonset.yaml

Line 181 in 524dcbc

image: sysdiglabs/falco-pubsub:latest

That makes Falco's chart hard to maintain Falco's chart too (here is an example).

Finally, falcosidekick (that's actively maintained, lives inside the falcosecurity org, and its chart is already inside this repository) already provides some of those integrations (missing ones are coming soon).

Feature

Remove the following integrations from the Falco's chart:

• gcscc (i.e., Google Cloud Security Command Center)
• natsOutput
• snsOutput
• pubsubOutput (i.e., Google Cloud Pub/Sub)

Finally, document how Falco's chart can integrate with those services by using falcosidekick's.

Alternatives

Do nothing. But sooner or later the current integrations will not work anymore.

Additional context

Service supported by falcosidekick:

• NATS
• SNS (recently added)
• PubSub (work already in progress)
• GCloud Security Command Center

Slack channel discussion 👇
https://kubernetes.slack.com/archives/CMWH3EH32/p1602690485207200

cc @Issif @nibalizer

[leogr]

cc'ing folks that might be using those integrations:
@fjudith @dza89 @NingPekin

[nibalizer]

I greatly agree, we can better support these kinds of things in the sidekick. I'd even say we should default the http output option to http://falco-sidekick:2801 or similar.

[Issif]

I even thought about integrating falcosidekick in falco's chart, as a dependency, what do you think about?

[nibalizer]

I'm not sure. I would like a single entry point for users. However I feel that bloated code and tons of options doesn't serve the users well. Separation is good, however Helm doesn't seem to have the best tooling to support collections of charts working together.

I found these two things:

• https://github.com/roboll/helmfile
• https://helm.sh/docs/chart_best_practices/dependencies/

Neither of which really looks all that great. It does seem like we could use

condition: falcosidekick.enabled

inside the main Falco chart to turn on http output to port 2801. That might be confusing for the users if http output is disabled in their values.yaml but enabled after they apply the chart.

I'm not against folding the sidekick chart into the main falco chart, I just worry that we're replacing one extension with another, and that in the future we'll probably be shy to change defaults in the falco chart and more willing to iterate and be disruptive to users in a separate chart.

[Issif]

I agree. I just wondered if we could just enable the import of falcosidekick"s chart with a boolean, but it doesn't seem possible with helm. When all will be ready in falcosidekick, its chart and this. I will write the relative documentation.

[Issif]

For GCloud Security Command Center, I checked the current implementation, it's just a simple curl. The webhook output in falcosidekick will work, it only needs a way to specify the Authorization Token as header, and this is possible since tonight, in that branch : https://github.com/falcosecurity/falcosidekick/tree/authorization-header.

After implementation of PubSub, falcosidekick will be fully able to replace these components.

[leogr]

Hey

I would like to introduce a deprecation notice in the Falco chart right now. WDYT?

[Issif]

@leogr It could be add in _helpers.tpl, I agree.

[leogr]

Update:
I believe the only missing piece now is the GCloud Security Command Center. So I'm starting to clean up the chart at this point.

[AbirHamzi]

Hello everyone, is it possible to introduce a readiness probe in falco to check that falcosidekick is available (when enabled ofc ) something like this maybe :

    readinessProbe:
      tcpSocket:
        host: falcosidekick
        port: 2801

I think this should be handled from falco side whenever a http output enabled a readiness probe should be added I mean not only for falcosidekick isn't ?

[Issif]

Hi @AbirHamzi,

For me, it's not the duty of falco to check if its backends are up and running. For the moment, falcosidekick is the "official" output extender but it may change in future if someone brings a better tool. We should not intricate them.

In kubernetes, falcosidekick deployment already has readiness and liveness probes:

          livenessProbe:
            httpGet:
              path: /ping
              port: http
            initialDelaySeconds: 10
            periodSeconds: 5
          readinessProbe:
            httpGet:
              path: /ping
              port: http
            initialDelaySeconds: 10
            periodSeconds: 5

And when you set in falco's config:

httpOutput:
  enabled: true
  url: "http://falcosidekick:2801/"

You use a kubernetes service that uses these probes.

[AbirHamzi]

@Issif okay if you see so, but just to clarify my point of view, I meant that from falco side if we enable the http output (for falcosidekick or any other server) we may set unreachable url by mistake (I did that :() we can see that in falco logs but I thought it's better to introduce it as readiness probe to save debugging time and we read values from values.yaml like following:

 {{- if .Values.httpOutput.enabled }}
   readinessProbe:
      tcpSocket:
        host: {{ .Values.httpOutput.host }}
        port: {{ .Values.httpOutput.port }}
{{- end }}

[leogr]

@Issif okay if you see so, but just to clarify my point of view, I meant that from falco side if we enable the http output (for falcosidekick or any other server) we may set unreachable url by mistake (I did that :() we can see that in falco logs but I thought it's better to introduce it as readiness probe to save debugging time and we read values from values.yaml like following:

 {{- if .Values.httpOutput.enabled }}
   readinessProbe:
      tcpSocket:
        host: {{ .Values.httpOutput.host }}
        port: {{ .Values.httpOutput.port }}
{{- end }}

I understand your point, and I agree the current solution needs to be improved, but I see an issue using the K8s probes. Falco could be restarted if the probe failed, and I don't believe that would be good. However, I still think we have to find a better way to inform the user when an output channel is misconfigured or is not working.
Btw, I had opened falcosecurity/falco#1466 about this topic.

[AbirHamzi]

@leogr yes I see what you mean, one last thing is it possible to keep the readiness probe and we set its failureThreshold high enough to avoid falco restarting in case of probe failure

[leogr]

@leogr yes I see what you mean, one last thing is it possible to keep the readiness probe and we set its failureThreshold high enough to avoid falco restarting in case of probe failure

It's hard to assume a default value for that a priori, IMHO. I'd rather leave open the ability to configure custom probes so that users may choose on a case-by-case basis.