2 Commits

Author	SHA1	Message	Date
Mark Stemm	0e1c436d14	Add jenkins checks (#584) ... * Supporting files to build/test via jenkins Changes to build/test via jenkins, which also means running all tests in a container instead of directly on the host: - Jenkinsfile controls the stages, build.sh does the build and run-tests.sh does the regression tests. - Create a new container falcosecurity/falco-tester that includes the dependencies required to run the regression tests. This is a different image than falco-builder because it doesn't need to be centos 6 based, doesn't install any compiler/etc, and installs the test running framework we use (avocado). We now use a newer version of avocado, which resulted in some small changes to how it is run and how yaml options are parsed. - Modify run_regression_tests.sh to download trace files to the build directory and only if not present. Also honor BUILD_TYPE/BUILD_DIR, which is provided via the docker run cmd. - The package tests are now moved to a separate falco_tests_package.yaml file. They will use rpm installs by default instead of debian packages. Also add the ability to install rpms in addition to debian packages. - Automate the process of creating the docker local package by: 1) Adding CMake rules to copy the Dockerfile, entrypoint to the build directory and 2) Copy test trace files and rules into the build directory. This allows running the docker build command from build/docker/local instead of the source directory. - Modify the way the container test is run a bit to use the trace files/rules copied into the container directly instead of host-mounted trace files. * Use container builder + tester for travis We'll probably be using jenkins soon, but this will allow switching back to travis later if we want. * Use download.draios.com for binutils packages That way we won't be dependent on snapshot.debian.org.	2019-04-26 12:24:15 -07:00
Mark Stemm	1f28f85bdf	K8s audit evts (#450) ... * Add new json/webserver libs, embedded webserver Add two new external libraries: - nlohmann-json is a better json library that has stronger use of c++ features like type deduction, better conversion from stl structures, etc. We'll use it to hold generic json objects instead of jsoncpp. - civetweb is an embeddable webserver that will allow us to accept posted json data. New files webserver.{cpp,h} start an embedded webserver that listens for POSTS on a configurable url and passes the json data to the falco engine. New falco config items are under webserver: - enabled: true|false. Whether to start the embedded webserver or not. - listen_port. Port that webserver listens on - k8s_audit_endpoint: uri on which to accept POSTed k8s audit events. (This commit doesn't compile entirely on its own, but we're grouping these related changes into one commit for clarity). * Don't use relative paths to find lua code You can look directly below PROJECT_SOURCE_DIR. * Reorganize compiler lua code The lua compiler code is generic enough to work on more than just sinsp-based rules, so move the parts of the compiler related to event types and filterchecks out into a standalone lua file sinsp_rule_utils.lua. The checks for event types/filterchecks are now done from rule_loader, and are dependent on a "source" attribute of the rule being "sinsp". We'll be adding additional types of events next that come from sources other than system calls. * Manage separate syscall/k8s audit rulesets Add the ability to manage separate sets of rules (syscall and k8s_audit). Stop using the sinsp_evttype_filter object from the sysdig repo, replacing it with falco_ruleset/falco_sinsp_ruleset from ruleset.{cpp,h}. It has the same methods to add rules, associate them with rulesets, and (for syscall) quickly find the relevant rules for a given syscall/event type. At the falco engine level, there are new parallel interfaces for both types of rules (syscall and k8s_audit) to: - add a rule: add_k8s_audit_filter/add_sinsp_filter - match an event against rules, possibly returning a result: process_sinsp_event/process_k8s_audit_event At the rule loading level, the mechanics of creating filterchecks objects is handled two factories (sinsp_filter_factory and json_event_filter_factory), both of which are held by the engine. * Handle multiple rule types when parsing rules Modify the steps of parsing a rule's filter expression to handle multiple types of rules. Notable changes: - In the rule loader/ast traversal, pass a filter api object down, which is passed back up in the lua parser api calls like nest(), bool_op(), rel_expr(), etc. - The filter api object is either the sinsp factory or k8s audit factory, depending on the rule type. - When the rule is complete, the complete filter is passed to the engine using either add_sinsp_filter()/add_k8s_audit_filter(). * Add multiple output formatting types Add support for multiple output formatters. Notable changes: - The falco engine is passed along to falco_formats to gain access to the engine's factories. - When creating a formatter, the source of the rule is passed along with the format string, which controls which kind of output formatter is created. Also clean up exception handling a bit so all lua callbacks catch all exceptions and convert them into lua errors. * Add support for json, k8s audit filter fields With some corresponding changes in sysdig, you can now create general purpose filter fields and events, which can be tied together with nesting, expressions, and relational operators. The classes here represent an instance of these fields devoted to generic json objects as well as k8s audit events. Notable changes: - json_event: holds a json object, used by all of the below - json_event_filter_check: Has the ability to extract values out of a json_event object and has the ability to define macros that associate a field like "group.field" with a json pointer expression that extracts a single property's value out of the json object. The basic field definition also allows creating an index e.g. group.field[index], where a std::function is responsible for performing the indexing. This class has virtual void methods so it must be overridden. - jevt_filter_check: subclass of json_event_filter_check and defines the following fields: - jevt.time/jevt.rawtime: extracts the time from the underlying json object. - jevt.value[<json pointer>]: general purpose way to extract any json value out of the underlying object. <json pointer> is a json pointer expression - jevt.obj: Return the entire object, stringified. - k8s_audit_filter_check: implements fields that extract values from k8s audit events. Most of the implementation is in the form of macros like ka.user.name, ka.uri, ka.target.name, etc. that just use json pointers to extact the appropriate value from a k8s audit event. More advanced fields like ka.uri.param, ka.req.container.image use indexing to extract individual values out of maps or arrays. - json_event_filter_factory: used by things like the lua parser api, output formatter, etc to create the necessary objects and return them. - json_event_formatter: given a format string, create the necessary fields that will be used to create a resolved string when given a json_event object. * Add ability to list fields Similar to sysdig's -l option, add --list (<source>) to list the fields supported by falco. With no source specified, will print all fields. Source can be "syscall" for inspector fields e.g. what is supported by sysdig, or "k8s_audit" to list fields supported only by the k8s audit support in falco. * Initial set of k8s audit rules Add an initial set of k8s audit rules. They're broken into 3 classes of rules: - Suspicious activity: this includes things like: - A disallowed k8s user performing an operation - A disallowed container being used in a pod. - A pod created with a privileged pod. - A pod created with a sensitive mount. - A pod using host networking - Creating a NodePort Service - A configmap containing private credentials - A request being made by an unauthenticated user. - Attach/exec to a pod. (We eventually want to also do privileged pods, but that will require some state management that we don't currently have). - Creating a new namespace outside of an allowed set - Creating a pod in either of the kube-system/kube-public namespaces - Creating a serviceaccount in either of the kube-system/kube-public namespaces - Modifying any role starting with "system:" - Creating a clusterrolebinding to the cluster-admin role - Creating a role that wildcards verbs or resources - Creating a role with writable permissions/pod exec permissions. - Resource tracking. This includes noting when a deployment, service, - configmap, cluster role, service account, etc are created or destroyed. - Audit tracking: This tracks all audit events. To support these rules, add macros/new indexing functions as needed to support the required fields and ways to index the results. * Add ability to read trace files of k8s audit evts Expand the use of the -e flag to cover both .scap files containing system calls as well as jsonl files containing k8s audit events: If a trace file is specified, first try to read it using the inspector. If that throws an exception, try to read the first line as json. If both fail, return an error. Based on the results of the open, the main loop either calls do_inspect(), looping over system events, or read_k8s_audit_trace_file(), reading each line as json and passing it to the engine and outputs. * Example showing how to enable k8s audit logs. An example of how to enable k8s audit logging for minikube. * Add unit tests for k8s audit support Initial unit test support for k8s audit events. A new multiplex file falco_k8s_audit_tests.yaml defines the tests. Traces (jsonl files) are in trace_files/k8s_audit and new rules files are in test/rules/k8s_audit. Current test cases include: - User outside allowed set - Creating disallowed pod. - Creating a pod explicitly on the allowed list - Creating a pod w/ a privileged container (or second container), or a pod with no privileged container. - Creating a pod w/ a sensitive mount container (or second container), or a pod with no sensitive mount. - Cases for a trace w/o the relevant property + the container being trusted, and hostnetwork tests. - Tests that create a Service w/ and w/o a NodePort type. - Tests for configmaps: tries each disallowed string, ensuring each is detected, and the other has a configmap with no disallowed string, ensuring it is not detected. - The anonymous user creating a namespace. - Tests for all kactivity rules e.g. those that create/delete resources as compared to suspicious activity. - Exec/Attach to Pod - Creating a namespace outside of an allowed set - Creating a pod/serviceaccount in kube-system/kube-public namespaces - Deleting/modifying a system cluster role - Creating a binding to the cluster-admin role - Creating a cluster role binding that wildcards verbs or resources - Creating a cluster role with write/pod exec privileges * Don't manually install gcc 4.8 gcc 4.8 should already be installed by default on the vm we use for travis.	2018-11-09 10:15:39 -08:00