[UMBRELLA] Requested Plugins

[Issif]

In January 2022, Falco introduced its first version of a Plugin framework to extend its available inputs. The framework has been enhanced in the following months to have something production ready for adopters.

Existing Plugins

We, the maintainers of Falco, created a bunch of Plugins to replace deprecated features (k8saudit) or to follow mediatic security events (Okta breach).

Right now, we have registered (excluding dummy plugins)

SDK

To make the development of plugins easier, 2 SDK are provided: Go and C++.
We can notice all plugins have been written in Go, it can be explained by several factors:
Go is easier to than C++
It’s a common language in web development, so in adopters’ infras
Falco’s ecosystem already embeds different Go codebases (Falcosidekick, Falcosidekick-UI, Falcoctl, Driverkit, Falco-exporter, Event-generator)

Libs

Writing a plugin from scratch could be complicated for the contributors, this is why we could also provide libraries to keep them focus on the extraction logic and not the asides (auth, polling, create a web server, etc). The main goal of these libs is to avoid duplicate codes across plugins, allowing to keep an uniformity.

This approach has been started with 2 libs for AWS:

• AWS Session: allows to create easily a session for AWS API
• AWS Cloudwatch: allows to set filters and starts the polling of log entries from Cloudwatch

To “open” Falco to more sources, we could create shared libs for generic usages:

• Web Server: to collect JSON webhook payloads
• File reader: to follow new entries in a file
• Kafka: to be a consumer of a topic
• SQS: to poll a queue
• RabbitMQ: to be a consumer of an exchange
• MQTT: for IoT

We also need to address the most common Cloud Providers and their specific log aggregator systems with the basic functions which are:

• Authentication to the API
• Creation of a client for the log service
• Gathering of logs
• Looping over the results

By providing these libs, it will be easier for developers to create new plugins for specific usages with these Cloud Providers.

Plugins

The purpose of this issue is to list the requested plugins by the community, the volunteers to develop them and their statuses.

The following table will be kept updated to avoid people to search through N issues.

Plugin	Description	Issue #	Developer	Repo URL	Status
k8saudit-gke	Collect K8S Audit Logs from GKE		@sboschman		Completed
k8saudit-aks	Collect K8S Audit Logs from AKS	#123	@NissesSenap		In Progress
k8saudit-openshift	Collect K8S Audit Logs from OpenShift				Requested
redshift	Collect Audit Logs from Redshift	#117			Requested
slack	Collect Audit Logs from Slack				Requested
k8saudit-admission	Collect Audit Logs from K8S Control Plane through an admission controller		@RichardoC	https://github.com/RichardoC/k8sadmission	In Progress

Tasks

Beta Give feedback

1. k8s audit plug-ins for AKS and GCP #243
   help wanted kind/feature +2
2. Request: Could a Falco plugin take over responsibility for the AKS Audit Log Forwarder from Sysdig? #368
   help wanted kind/feature lifecycle/stale +3
   
3. Add a plugin for Azure AKS k8_audit #123
   kind/feature lifecycle/rotten +2

[NissesSenap]

@Issif sadly I won't be able to work on the k8saudit-aks feature due to that I have changed job and I don't use Azure anymore.
I might be able to look at the GKE feature, but it won't happen for at least 6 months (have lots of other stuff I have to fix first).

[Issif]

@NissesSenap no problem, I get that. If you have a WIP repo, please share it as reference

[NissesSenap]

Sadly, I never got that far

[Issif]

Np

[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

[jasondellaluce]

/remove-lifecycle stale

[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

[poiana]

Stale issues rot after 30d of inactivity.

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

Rotten issues close after an additional 30d of inactivity.

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

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

/lifecycle rotten

[Andreagit97]

/remove-lifecycle rotten

[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

[sboschman]

Hi, I have been working on a k8saudit-gke plugin. Currently I have it deployed in our Falco pipeline to test drive. Still needs a bit of documentation and code cleanup, so it is not ready for a pr yet.

Once I am ready to open a pr, is anyone from the Falco team willing to assist in getting it merged into the plugins codebase? Helping out with practical stuff like reserving a plugin ID, maybe bumping the go version in the ci workflow and having the ci rule validator accept gke specific modification rules (1). Can you arrange help @Issif , or ?

---

(1) It seems the validator only accepts a complete rule with all fields. The gke specific rules file I made uses the new override section to modify the k8s audit rules from the k8saudit plugin, so the gke specific stuff is not in the default/base/standard k8saudit rules file.
I noticed the default k8saudit rules do contain EKS specific rule extensions. My concern is this might compromise the effectiveness of Falco's threat detection. For example EKS system 'users' (like eks:node-manager) are excluded from triggering rules. I can imagine these system user names are protected/enforced by EKS, and you can not create them yourself. But on a different cloud these names might not be protected, allowing a shady person to use these usernames to bypass Falco's detection rules.

[Issif]

I can help you for sure. For the CI, we need to see with @jasondellaluce too

[Issif]

/assign

[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

[poiana]

Stale issues rot after 30d of inactivity.

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

Rotten issues close after an additional 30d of inactivity.

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

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

/lifecycle rotten

[poiana]

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

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

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

[poiana]

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

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

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

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.