Refactor how JSON event/k8s audit events extract values in two important ways: 1. An event can now extract multiple values. 2. The extracted value is a class json_event_value instead of a simple string. The driver for 1. was that some filtercheck fields like "ka.req.container.privileged" actually should extract multiple values, as a pod can have multiple containers and it doesn't make sense to summarize that down to a single value. The driver for 2. is that by having an object represent a single extracted value, you can also hold things like numbers e.g. ports, uids, gids, etc. and ranges e.g. [0:3]. With an object, you can override operators ==, <, etc. to do comparisons between the numbers and ranges, or even set membership tests between extracted numbers and sets of ranges. This is really handy for a lot of new fields implemented as a part of PSP support, where you end up having to check for overlaps between the paths, images, ports, uids, etc in a K8s Audit Event and the acceptable values, ranges, path prefixes enumerated in a PSP. Implementing these changes also involve an overhaul of how aliases are implemented. Instead of having an optional "formatting" function, where arguments to the formatting function were expressed as text within the index, define optional extraction and indexing functions. If an extraction function is defined, it's responsible for taking the full json object and calling add_extracted_value() to add values. There's a default extraction function that uses a list of json_pointers with automatic iteration over array values returned by a json pointer. There's still a notion of filter fields supporting indexes--that's simply handled within the default extraction or custom extraction function. And for most fields, there won't be a need to write a custom extraction function simply to implement indexing. Within a json_event_filter_check object, instead of having a single extracted value as a string, hold a vector of extracted json_event_value objects (vector because order matters) and a set of json_event_value objects (for set comparisons) as m_evalues. Values on the right hand side of the expression are held as a set m_values. json_event_filter_check::compare now supports IN/INTERSECTS as set comparisons. It also supports PMATCH using path_prefix_search objects, which simplifies checks like ka.req.pod.volumes.hostpath--now they can be expressed as "ka.req.pod.volumes.hostpath intersects (/proc, /var/run/docker.sock, /, /etc, /root)" instead of "ka.req.volume.hostpath[/proc]=true or ka.req.volume.hostpath[/root]=true or ...". Define ~10 new filtercheck fields that extract pod properties like hostIpc, readOnlyRootFilesystem, etc. that are relevant for PSP validation. As a part of these changes, also clarify the names of filter fields related to pods to always have a .pod in the name. Furthermore, fields dealing with containers in a pod always have a .pod.containers prefix in the name. Finally, change the comparisons for existing k8s audit rules to use "intersects" and/or "in" when appropriate instead of a single equality comparison. Signed-off-by: Mark Stemm <mark.stemm@gmail.com> |
||
---|---|---|
.github | ||
cmake/modules | ||
cpack/debian | ||
docker | ||
examples | ||
integrations | ||
proposals | ||
rules | ||
scripts | ||
test | ||
tests | ||
userspace | ||
.clang-format | ||
.cmake-format | ||
.gitignore | ||
.luacheckrc | ||
.travis.yml | ||
.yamllint.conf | ||
ADOPTERS.md | ||
CHANGELOG.md | ||
CMakeCPackOptions.cmake | ||
CMakeLists.txt | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
COPYING | ||
falco.yaml | ||
GOVERNANCE.md | ||
OWNERS | ||
README.md |
Falco
Latest release
v0.17.1 Read the change log
Dev Branch:
Master Branch:
CII Best Practices:
Falco is a behavioral activity monitor designed to detect anomalous activity in your applications. Powered by sysdig’s system call capture infrastructure, Falco lets you continuously monitor and detect container, application, host, and network activity—all in one place—from one source of data, with one set of rules.
Falco is hosted by the Cloud Native Computing Foundation (CNCF) as a sandbox level project. If you are an organization that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF. For details read the Falco CNCF project proposal.
What kind of behaviors can Falco detect?
Falco can detect and alert on any behavior that involves making Linux system calls. Falco alerts can be triggered by the use of specific system calls, their arguments, and by properties of the calling process. For example, Falco can easily detect incidents including but not limited to:
- A shell is running inside a container.
- A container is running in privileged mode, or is mounting a sensitive path, such as
/proc
, from the host. - A server process is spawning a child process of an unexpected type.
- Unexpected read of a sensitive file, such as
/etc/shadow
. - A non-device file is written to
/dev
. - A standard system binary, such as
ls
, is making an outbound network connection.
Installing Falco
A comprehensive installation guide for Falco is available in the documentation website.
How do you compare Falco with other security tools?
One of the questions we often get when we talk about Falco is “How does Falco differ from other Linux security tools such as SELinux, AppArmor, Auditd, etc.?”. We wrote a blog post comparing Falco with other tools.
Documentation
See Falco Documentation to quickly get started using Falco.
Join the Community
- Join the mailing list for news and a Google calendar invite for our Falco open source meetings. Note: this is the only way to get a calendar invite for our open meetings.
- Website for Falco.
- Join our Public Slack channel for open source Sysdig and Falco announcements and discussions.
Office hours
Falco has bi-weekly office hour style meetings where we plan our work on the project. You can get a Google calendar invite by joining the mailing list. It will automatically be sent.
Wednesdays at 8am Pacific on Zoom.
License Terms
Falco is licensed to you under the Apache 2.0 open source license.
Contributing
See the CONTRIBUTING.md.