repository·master·Indexed 11 days ago
https://github.com/falcosecurity/falcoA CNCF-graduated, cloud-native runtime security tool for Linux that monitors syscalls and system events to detect abnormal behavior and security threats in real-time. It supports multiple drivers, including a Modern eBPF Probe and Kernel Modules, and can be deployed in Kubernetes via Helm as a DaemonSet or Deployment. Falco utilizes plugins like k8smeta and k8saudit for extended metadata and audit log monitoring, and manages rules and artifacts using the falcoctl tool.
Falcosecurity publishes several types of official artifacts, which are intended for General Availability (GA) unless otherwise specified in release notes.
Official Artifact Types:
kmod, eBPF)Official Distribution Channels: To ensure you are using authentic artifacts, verify the channel against the official list at falco.org.
HTTP Distribution (Best for humans, simple scripts, or legacy clients):
https://download.falco.org/ (Primary location for most file artifacts)Falcosecurity organization (e.g., release downloads, GitHub Pages).OCI Distribution (Best for automated consumers like falcoctl and compatible container runtimes):
docker.io (Docker Hub): Reserved primarily for container images.ghcr.io (GitHub Packages): Used for container images and other artifacts like plugins or rules.Note: If you are downloading files via HTTP, ensure the versioning and architecture in the filename match your requirements (e.g., falco-0.33.0-x86_64.tar.gz).
The Falco plugin system is an infrastructure designed to extend the functionality of the Falco libraries (libscap and libsinsp). It allows users to extend the capabilities of Falco and other tools built on these libraries without requiring recompilation or relinking. The system is designed to be modular, efficient, and language-agnostic (with primary support for Go, C, and C++), enabling support for multiple platforms including Linux, MacOS, and Windows.
Currently, the proposal focuses on two primary plugin types:
The Falco API is a set of gRPC-based contracts designed to decouple Falco from its input sources and make it more extensible. It allows third-party clients to interface with Falco's outputs, inputs, rules, and configurations. The architecture consists of a single gRPC server that groups several services together, defined via .proto files.
The API is categorized into three types of service patterns:
To understand the impact of a Falco update, distinguish between these three types of changes:
syscall data source) can now be managed as separate artifacts using falcoctl. This allows for dedicated versioning and independent updates of rulesets without requiring a full Falco binary release. This mechanism is consistent with how plugin rules are consumed.The falcoctl.artifact.follow configuration runs a sidecar container that automatically checks for updates to Falco artifacts (like rules). If an update is found, it downloads and installs it into a shared emptyDir volume accessible by the main Falco container. The tool ensures compatibility with the running Falco version before applying updates.
Configuration options for the sidecar:
falcoctl.artifact.follow.args: Arguments passed to the sidecar (e.g., ["--log-format=json"]).falcoctl.artifact.follow.env: Extra environment variables.falcoctl.artifact.follow.mounts: Volume mounts for the sidecar.falcoctl.artifact.follow.resources: CPU/Memory requests and limits for the sidecar.falcoctl.artifact.follow.securityContext: Security context for the sidecar.falcoctl:
artifact:
follow:
enabled: true
args: ["--log-format=json"]Starting from chart version v0.3.0, Falco uses the falcoctl tool to manage artifacts (rules files and plugins) instead of shipping them inside the Docker image.
The chart deploys two helper containers to manage this:
falcoctl-artifact-install: An init container that installs configured artifacts before the main Falco container starts.falcoctl-artifact-follow: A sidecar container that periodically checks for and downloads new artifacts (like falco-rules).When a feature or behavior is deprecated, Falco provides several signals to help you migrate:
DEPRECATED in all relevant documentation.Note that Sandbox features do not follow these deprecation rules and can be removed without notice.
Structured exceptions allow you to define specific sets of field values that, when matched, prevent a rule from triggering. Instead of manually appending and not macro to a rule's condition, you define an exceptions key within the rule. This provides a cleaner, more controlled way to manage allowed behaviors.
In the rule definition, use the exceptions key to specify which fields constitute a valid exception. Each exception needs a name (an arbitrary identifier) and a set of fields. You can also specify custom comparison operators using the comps key.
fields: A list of field names used to identify the exception.comps: (Optional) A list of comparison operators corresponding to the fields (e.g., [=, startswith]). If omitted, the = operator is used by default.To apply the exceptions, use append: true in your user rules to provide the actual values for the named exceptions defined in the rule.
[proc.name, fd.directory]), the values list must contain lists of values (tuples) matching those fields.values list contains the values directly.An exception triggers (and prevents the rule from firing) if all fields in an exception item match the values provided.
# 1. The Rule Definition
- rule: Write below binary dir
condition: >
bin_dir and evt.dir = < and open_write
exceptions:
- name: proc_writer
fields: [proc.name, fd.directory]
- name: container_writer
fields: [container.image.repository, fd.directory]
comps: [=, startswith]
- name: proc_filenames
fields: [proc.name, fd.name]
comps: [=, in]
- name: filenames
fields: fd.filename
comps: in
# 2. Providing the Values (in user rules)
- rule: Write below binary dir
exceptions:
- name: proc_writer
values:
- [apk, /usr/lib/alpine]
- [npm, /usr/node/bin]
- name: container_writer
values:
- [docker.io/alpine, /usr/libexec/alpine]
- name: proc_filenames
values:
- [apt, apt_files] # 'apt_files' can be an existing list name
- [rpm, [/bin/cp, /bin/pwd]]
- name: filenames
values: [python, go]The Falco roadmap is managed using a GitHub Project (the Falco Roadmap project) to track progress across release cycles.
Key components of the planning process include:
falcosecurity/libs), their release schedules must be synchronized. For example, a libs release may be required at least one week before the end of a Falco iteration to ensure compatibility.In recent versions of Falco, libscap and libsinsp are no longer compiled directly into the Falco binary. Instead, they are distributed as standalone artifacts. When installing Falco via package managers (like deb or rpm), these libraries are now treated as install dependencies.
To ensure compatibility when building or running Falco, ensure that the corresponding libsinsp and libscap packages are installed on your system.