ROADMAP: Improved Falco Outputs

[mfdii]

Description: The goal behind this idea is to improve the available options for sending alerts from Falco when a security violation occurs inside a container. Currently outputs are limited to stdout, files, syslog, and executing a program. We’d like to offer more output options such as: NATS.io, Kafka, gRPC, Google Pub/Sub, AWS SNS, HTTPs Webhooks, etc.
Also, currently, Falco only supports a single program output. We want it to support multiple program_outputs instead.
Recommended Skills: C/C++ experience, working with external libraries, working knowledge of message queues and modern Pub/Sub systems.
Mentor(s): Mark Stemm (@mstemm), Loris Degioanni (@ldegio), Michael Ducy (@mfdii)

[mfdii]

This pr (#523) shows how to implement an output handler. It also shows how to leverage C++ functions in Lua which makes it easier to use C/C++ libraries for the output destination.

[laphets]

Hello, I'd like to contribute to this idea, can someone give me advice on how to get start with the project :) Thanks!

[mfdii]

@laphets I've made sure that we have issues tagged with help wanted. These are various issues we need fixed and might provide a better opportunity to get started with the project. Also there are rules you can contribute to in the falcosecurity/profiles repo. For adding additional output destinations, you should review #523 to understand what code changes need to be made to add an output. Feel free to ping me on Slack if you have more questions.

A GRPC output might be a good start. We are investigating the idea of using sidecar containers to provide the various output destinations for Falco and being able to tie the containers together with GRPC would be better than the current implementation of a named pipe.

[fntlnz]

@mfdii I think that the output of this will be to implement a gRPC streaming service to stream events.
In that way we can decouple completely Falco from its outputs by having plugins implement the client part in any language with gRPC support.

This is a good idea for multiple reasons

• Easy to contribute outputs: you're not tied to C++ to make your output, you can write and debug outputs on a machine that is not supported by Falco since it is decoupled
• gRPC supports authentication
• Services and rpc contracts are easy to version, we can enable or disable features based on the combination of Falco version and Output version

[Issif]

For following up some discussions we had on Slack, here a quick schema about basic principles I had in mind. A lot are inspired by my falcosidekick with some enhancements I wanted to add (queues + gRPC)

Feel free to discuss about and challenge.

The main challenge will be to formalize and standardize how we implement plugins, those could be in any language, only interfaces matters and that let anybody write and propose a new output.

[leodido]

/kind design