Cloud Native Runtime Security
Go to file
Mark Stemm 154dd18c8f JSON/K8s Audit Evts extract multiple typed values
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>
2019-10-15 19:45:31 +02:00
.github update(.github): proposals area into PR template 2019-10-08 16:11:43 +02:00
cmake/modules update: license headers 2019-10-08 16:02:26 +02:00
cpack/debian Add ability to read rules files from directories (#348) 2018-04-05 17:03:37 -07:00
docker update: refer to latest probeinstaller library in falcoctl/pkg 2019-10-11 19:43:56 +02:00
examples update: license headers 2019-10-08 16:02:26 +02:00
integrations docs: reflect the changes to probeloader docker images 2019-10-11 19:43:56 +02:00
proposals chore(proposals): apply code review about PSP rules proposal 2019-10-14 13:59:15 +02:00
rules JSON/K8s Audit Evts extract multiple typed values 2019-10-15 19:45:31 +02:00
scripts update: license headers 2019-10-08 16:02:26 +02:00
test update: license headers 2019-10-08 16:02:26 +02:00
tests Add explicit catch2 dependency for tests 2019-10-08 16:12:18 +02:00
userspace JSON/K8s Audit Evts extract multiple typed values 2019-10-15 19:45:31 +02:00
.clang-format chore: clang format following the current style 2019-07-03 09:07:00 +02:00
.cmake-format new: cmake format file 2019-07-08 19:05:06 +02:00
.gitignore fix: ignore build files generated by the regression tests 2019-08-13 15:48:06 +02:00
.luacheckrc new: luacheck basic config 2019-07-10 18:49:02 +02:00
.travis.yml update: license headers 2019-10-08 16:02:26 +02:00
.yamllint.conf new: YAML lint configuration 2019-07-10 13:00:03 +02:00
ADOPTERS.md Added more context on Sysdig Secure in Adopters.md 2019-10-10 12:59:03 +02:00
CHANGELOG.md update(changelog): prepare for v0.17.1 2019-09-26 16:14:25 +02:00
CMakeCPackOptions.cmake update: license headers 2019-10-08 16:02:26 +02:00
CMakeLists.txt update: license headers 2019-10-08 16:02:26 +02:00
CODE_OF_CONDUCT.md docs: markdown code of conduct 2019-09-13 12:57:17 +02:00
CONTRIBUTING.md docs: markdown code of conduct 2019-09-13 12:57:17 +02:00
COPYING docs: update COPYING 2019-10-08 16:02:26 +02:00
falco.yaml update: license headers 2019-10-08 16:02:26 +02:00
GOVERNANCE.md docs: markdown governance 2019-09-13 12:57:17 +02:00
OWNERS new: add @kris-nova to owners 2019-08-13 22:42:43 +02:00
README.md update(changelog): prepare for v0.17.1 2019-09-26 16:14:25 +02:00

Falco

Latest release

v0.17.1 Read the change log

Dev Branch: Build Status
Master Branch: Build Status
CII Best Practices: CII Best Practices


Falco is a behavioral activity monitor designed to detect anomalous activity in your applications. Powered by sysdigs 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.