Guest post from Falco project maintainers Kris Nóva (Sysdig), Lorenzo Fontana (Sysdig), Spencer Krum (IBM), Kaizhe Huang (Sysdig), Leonardo Di Donato (Sysdig)
A lot has happened in the world since the Falco maintainers were face to face at KubeCon San Diego last November. Regardless, we have been hard at work trying to make The Falco Project as clean and composable as possible.
The Falco Project, originally created by Sysdig, is a CNCF open source cloud native runtime security tool. The premise behind the tooling is fairly straightforward, but the details are another story. Essentially, Falco makes it easy to consume kernel events, and enrich those events with information from Kubernetes and the rest of the stack. Falco has a rich rule set of security rules specifically built for Kubernetes, Linux, and cloud-native stacks. If a rule is violated in a system, Falco will send an alert notifying the user of the violation and its severity.
We have some exciting features we’ve been busy working on that we want to share with the ecosystem. There are a lot, but below are the top five new features the Falco community picked to share.
#1 Falco Rules Improvements
Falco has been diligently improving our work around Falco rules. We introduced a new feature that allows Falco to natively understand Kubernetes PodSecurityPolicy. We added another new feature where Falco alerts are now tagged to the Mitre ATT&CK(tm) classification matrix, enabling at-a-glance situation assessments and long-term reporting. We have also introduced many new rules for known CVEs that are documented in the Falco blog. A couple of Falco rules worth mentioning in particular are: “Detect outbound connections to common miner pool ports” and “Detect crypto miners using the Stratum protocol.” We are fortunate to have the community that contributed the known crypto pool domains. Meanwhile, as a security product, we have been working hard to catch up on the latest known malicious patterns to improve Falco’s detection capabilities by leveraging the powerful Falco policy engine and the flexible Falco rule syntax. On the other hand, we worked with the community closely to reduce False Positives generated by the Falco rules.
#2 Community Improvements
The Falco Project has defined multiple levels at which work is scoped, as well as a charter of work for the project release artifacts. We have released seven (0.19+) production versions of Falco using the defined artifacts above, which are all documented in the Falco blog. We have simplified our container image releases that call out the relationship between Pods and Nodes in reference to a security boundary between them, and how a driver is installed on the host. The Falco project has weekly community calls where everyone is welcome to attend, and we have officially moved to the Kubernetes slack and have a public mailing list. Join us!
#3 gRPC for Falco alerts
One of the most exciting features is the new gRPC output mechanism that enables users to consume Falco security alerts over a mTLS authenticated API over gRPC. The gRPC methods and the messages they accept and return are defined in Protobuf and the community has built out SDKs in Rust, Go, and Python. This enables flexible infrastructure with Falco where users can consume alerts in any way that works for them. Users can simply subscribe to receive Falco alerts as they happen or they can obtain all the alerts Falco has at some point in time and close the connection. For those interested in a simpler architecture and faster ramp-up, Falco can also listen for gRPC connections over a UNIX domain socket.
Anybody interested in knowing more about this exciting feature, how it has been done, and the future plans we have for it, should join the Falco Deep Dive Maintainers Track at KubeCon.
#4 Community Integrations
The new gRPC mechanism has enabled many third-party integrations with Falco. The Falco exporter is a tool that consumes Falco alerts and sends them to a Prometheus server. You can find a tutorial here.
- Slack, Rocketchat, Mattermost, Teams, Discord
- Datadog, AlertManager, Elasticsearch, Loki, NATS, Influxdb
- AWS Lambda, AWS SQS, Azure Event Hubs
- SMTP, Opsgenie, StatsD, DogStatsD
Falco has improved the experience for users installing via Helm. Helm customers can now use and visit our Helm repository. We’ve collected all the charts related to Falco (Falco, the exporter, and the sidekick) into one repo with a consistent coding style and release process.
Now, Falco can also be executed in Minikube; here is a tutorial on how to set it up.
#5 Falco Driver Improvement
The Falco driver is the heart of the entire system. We have re-engineered how we build and deploy the driver in Kubernetes to respect various Pod-Node security boundaries. We also pre-build drivers for well-known kernels.
Falco currently has three primary ways of tracing the Linux kernel
- Kernel module
- eBPF probe
- Our newest driver pdig
Different environments can take advantage of the different drivers. The latest driver is built on ptrace(2) and provides a way to run Falco without needing access to the host. The pdig driver uses CAP_SYS_PTRACE to trace the kernel from userspace. More information can be found here, and a working example of how to run this with AWS Fargate can be found here.
The Falco pipeline can best be seen in our GitHub milestones.
There are some exciting new features to come in the future. For one, we are working on ARM64 support! We are also looking at building out composable input mechanisms, like that of our gRPC output mechanism, for dynamically sending data to the Falco engine.
Please feel welcome in the community, and come join the party.