# Falco security monitoring with Edera Edera integrates with [Falco](https://falco.org/), the cloud-native runtime security project, to provide deep observability into protected zones. Using eBPF-based syscall monitoring, Falco can detect threats, policy violations, and suspicious activity as workloads run inside Edera’s hypervisor-isolated zones. While Edera mitigates container escapes and access to shared host resources, security observability is a crucial aspect of defense-in-depth. This guide shows you how to configure the Edera plugin for Falco and start monitoring zone activity with custom security rules. ## What you’ll learn - How the Edera Falco plugin works - How to configure Falco to monitor Edera zones - How to write rules that trigger on zone activity - How to verify events are streaming from your zones ## Prerequisites Before you begin, make sure you have: - **Edera Protect installed** and the daemon running (`/var/lib/edera/protect/daemon.socket` available) - **Falco installed** (version 0.41.0 or later recommended) - either: - Directly on nodes via package manager (yum/apt), OR - Via Helm charts in your Kubernetes cluster - **Root or sudo access** (for node-based installation) OR **Helm access** (for Kubernetes installation) - **At least one Edera zone** you can launch for testing ## How it works The Edera Falco plugin bridges Falco’s runtime security engine with Edera’s zone isolation. Here’s the architecture: ```bash ┌─────────────────────────────────────────────────────────────────────────────┐ │ Host (Dom0) │ │ │ │ ┌──────────────────────────────────────────────────────────────────────┐ │ │ │ Falco (runtime security engine) │ │ │ │ │ │ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Edera Plugin (libedera_falco_plugin.so) │ │ │ │ │ │ │ │ │ │ │ │ • Zone discovery & management │ │ │ │ │ │ • Thread/FD snapshot tables (per zone) │ │ │ │ │ │ • Event enrichment & context tracking │ │ │ │ │ └─────────────────────┬──────────────────────────────────────────┘ │ │ │ │ │ │ │ │ │ │ (3) Connect to daemon socket │ │ │ │ ▼ │ │ │ └──────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ┌────────────────────────▼────────────────────────────────────────────┐ │ │ │ Edera Daemon │ │ │ │ (/var/lib/edera/protect/daemon.socket) │ │ │ │ │ │ │ │ • Zone lifecycle management │ │ │ │ • IDM channel host │ │ │ │ • Hypervisor interface (Xen) │ │ │ └─────────────────────┬──────────────────┬────────────────────────────┘ │ │ │ │ │ │ │ (4) Query zones │ (5) Monitor syscalls (IDM msg) │ │ │ │ │ └────────────────────────┼──────────────────┼─────────────────────────────────┘ │ │ ╪══════════════════╪ │ Hypervisor (Xen) │ │ • Memory/CPU │ │ • Event channels│ ╪══════════════════╪ │ │ ▼ ▼ ┌────────────────────────────────────────────────────────────────────────────┐ │ Zone - MicroVM │ │ │ │ ┌────────────────────────────────────────────────────────────────────┐ │ │ │ Zone kernel (Linux PV/PVH) │ │ │ │ │ │ │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ │ │ libscap_rs (loaded on demand by monitor syscalls message) │ │ │ │ │ │ │ │ │ │ │ │ • Installs eBPF programs in zone kernel context │ │ │ │ │ │ • Snapshots threads & file descriptors │ │ │ │ │ │ • Harvests syscall events via eBPF │ │ │ │ │ └────────────────┬──────────────────────────────────────────┘ │ │ │ │ │ │ │ │ │ │ (6) Syscall events │ │ │ │ │ │ │ │ └───────────────────┼────────────────────────────────────────────────┘ │ │ │ │ │ ┌───────────────────▼──────────────────────────────────────────────┐ │ │ │ Styrolite (container runtime) │ │ │ │ │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ │ │ Workload (OCI container) │ │ │ │ │ │ │ │ │ │ │ │ • Application processes │ │ │ │ │ │ • open(), read(), write(), execve(), connect()... │ │ │ │ │ │ │ │ │ │ │ │ (All syscalls monitored by eBPF probes above) │ │ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────────┘ │ │ │ │ │ │ (7) Stream events over IDM │ │ ▼ │ │ ┌──────────────────────────────────────────────────────────────────┐ │ │ │ IDM Client (protobuf over shared memory + event channels) │ │ │ └─────────────────────────┬────────────────────────────────────────┘ │ └────────────────────────────┼───────────────────────────────────────────────┘ │ │ (8) Enriched event stream │ ▼ ┌────────────────────────────────────────────────────────────────────────────┐ │ Back to Edera Plugin in Host │ │ │ │ • Receives syscall events over IDM │ │ • Updates thread/FD tables with new state │ │ • Enriches events with contextual data (process tree, FD mappings) │ │ • Exposes enriched events to Falco rules engine │ │ │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ Falco Rules Engine │ │ │ │ │ │ │ │ • Evaluates security rules against event stream │ │ │ │ • Matches conditions (file paths, processes, syscalls) │ │ │ │ • Generates alerts on rule violations │ │ │ └──────────────────────────────────────────────────────────────┘ │ │ │ │ Output: Security alerts, logs, SIEM integration │ └────────────────────────────────────────────────────────────────────────────┘ ``` ### Event flow 1. **Plugin loads** - Falco loads `/var/lib/edera/protect/falco/libedera_falco_plugin.so` at startup 2. **Zone discovery** - The plugin connects to `/var/lib/edera/protect/daemon.socket` and queries for running zones 3. **eBPF instrumentation** - For each zone, the plugin sends a “monitor syscalls” message over Edera’s IDM (inter-domain messaging), which: - Instructs the zone binary to load `libscap_rs` - Installs eBPF programs inside the zone’s kernel context. These eBPF programs are the same ones used by upstream Falco on the host, and support the same kinds of hooks and syscalls. - Snapshots all threads and file descriptors currently running in the zone - Begins streaming syscall events back to the host over IDM 4. **Event enrichment** - The plugin maintains internal thread and FD tables for each zone, using snapshot data and live events to enrich context 5. **Rule evaluation** - Falco evaluates your security rules against the enriched event stream 6. **Cleanup** - When zones terminate, their monitoring tables are automatically purged If a CPU hotplug event is detected inside a zone, the plugin disconnects and reconnects to avoid stale cache data. This is similar to Falco’s behavior on bare metal, but doesn’t require restarting the Falco agent. ## Configuration The configuration steps differ based on your Falco installation method. Choose the section that matches your setup: - **[Node-based installation](https://docs.edera.dev/guides/observability/falco-integration/#node-based-installation)** - Falco installed directly on nodes via yum/apt - **[Helm-based installation](https://docs.edera.dev/guides/observability/falco-integration/#helm-based-installation)** - Falco deployed as a Kubernetes DaemonSet ## Node-based installation Follow these steps if you installed Falco directly on your nodes using a package manager (yum, apt, etc.). ### Step 1: Configure the Edera plugin Edit `/etc/falco/falco.yaml` and add the Edera plugin to the `plugins` section: ```yaml plugins: - name: container library_path: libcontainer.so init_config: label_max_len: 100 with_size: false - name: edera library_path: /var/lib/edera/protect/falco/libedera_falco_plugin.so ``` This tells Falco where to find the Edera plugin shared library. `mirror_host_syscalls: false` configures each zone to monitor the full set of syscalls that Falco supports. This is the recommended default—it gives you complete visibility and lets you write zone-specific rules from scratch. Setting `mirror_host_syscalls: true` restricts zones to only the syscalls that Falco is already monitoring on the host kernel. This is only useful if you have a pre-existing host Falco deployment and want zones to emit the same narrow event set. In practice, zone security rules are written independently of host rules, so most deployments should use `false`. ### Step 2: Enable the Edera plugin Create `/etc/falco/config.d/falco.edera_plugin.yaml` to explicitly load the Edera plugin: ```yaml load_plugins: [edera] ``` ### Step 3: Add detection rules Edit `/etc/falco/falco_rules.yaml` (or create a custom rules file) and add rules for Edera zone events. See [Example rules](https://docs.edera.dev/guides/observability/falco-integration/#example-rules) below for attack-focused detection rules you can start with. ### Step 4: Restart Falco Restart the Falco service to apply your configuration changes: ```bash sudo systemctl restart falco ``` ## Helm-based installation Follow these steps if you installed Falco via Helm charts in your Kubernetes cluster. **Security considerations**: Deploying privileged node-level security tools like Falco via Kubernetes and Helm requires mounting sensitive host paths (daemon sockets, plugin binaries) into pods. While this approach is widely used and supported, it introduces additional attack surface compared to installing Falco directly on nodes via package managers. For production environments with strict security requirements, we recommend installing Falco directly on nodes using the [node-based installation method](https://docs.edera.dev/guides/observability/falco-integration/#node-based-installation). This provides better isolation and follows the principle of least privilege. If you choose the Helm-based approach, ensure you: - Restrict access to the Falco namespace using Kubernetes RBAC - Audit the Falco Helm chart and container images before deployment - Monitor Falco pod activity and limit network access where possible - Follow Falco’s security best practices for production deployments ### Step 1: Create Helm values file When Falco runs as a Kubernetes DaemonSet, the configuration must be provided through Helm values rather than editing files on the node. The Falco pods need to mount the Edera plugin and daemon socket from the host. Create a file called `falco-edera-values.yaml`: ```yaml # Mount Edera plugin and daemon socket from host into Falco pods mounts: volumes: - name: edera-plugin hostPath: path: /var/lib/edera/protect/falco - name: edera-daemon-socket hostPath: path: /var/lib/edera/protect volumeMounts: - name: edera-plugin mountPath: /var/lib/edera/protect/falco readOnly: true - name: edera-daemon-socket mountPath: /var/lib/edera/protect readOnly: false # Configure the Edera plugin falco: plugins: - name: edera library_path: /var/lib/edera/protect/falco/libedera_falco_plugin.so load_plugins: [edera] # Add custom Edera detection rules (see "Example rules" section for more) customRules: edera-rules.yaml: |- - rule: Edera Proc Environ Read desc: > Detect reads of /proc/*/environ inside an Edera zone. Credential harvesting via procfs is a common post-exploitation technique for extracting secrets from neighboring workloads. source: edera_zone output: > Credential harvesting attempt in zone (zone_id=%edera.zone.id proc=%proc.exe file=%fd.name) priority: WARNING condition: > evt.pluginname == "edera" and evt.type in (open, openat) and fd.name glob /proc/*/environ - rule: Edera Process Execution desc: Logs process executions inside Edera zones source: edera_zone output: > Process executed in zone (zone_id=%edera.zone.id proc=%proc.exe cmdline=%proc.cmdline) priority: NOTICE condition: > evt.pluginname == "edera" and evt.type in (execve, execveat) ``` ### Step 2: Upgrade Falco with the new configuration Apply the configuration by upgrading your Falco Helm release: ```bash helm upgrade falco falcosecurity/falco \ -n falco \ -f falco-edera-values.yaml ``` This will: - Mount the Edera plugin library and daemon socket into Falco pods - Configure the Edera plugin - Add custom detection rules for monitoring zone activity ### Step 3: Verify Falco pods are running Check that the Falco pods have restarted and are running: ```bash kubectl get pods -n falco ``` You can check the Falco logs to see if the plugin loaded successfully: ```bash kubectl logs -n falco -l app.kubernetes.io/name=falco | grep -i edera ``` ## Step 4: Launch a zone (node-based) Start a test zone with a `nginx` workload so you have something to monitor: ```bash sudo protect zone launch \ --name nginx \ --kernel-verbose sudo protect workload launch \ --zone nginx \ --name nginx \ docker.io/library/nginx:alpine ``` ## Step 5: Stream Falco events The method to view Falco events depends on your installation type: ### For node-based installations Run Falco in the foreground with debug logging to see events as they arrive: ```bash sudo falco -o "log_level=debug" ``` ### For Helm-based installations Stream the logs from a Falco pod: ```bash kubectl logs -n falco -l app.kubernetes.io/name=falco -f ``` To see debug-level logging, you can enable it in your Helm values: ```yaml falco: log_level: debug ``` Then upgrade the release: ```bash helm upgrade falco falcosecurity/falco \ -n falco \ -f falco-edera-values.yaml ``` ### Expected output You should see Falco discover your zone, install eBPF probes, and begin streaming events: ```bash Thu Oct 30 20:30:29 2025: [libs]: edera: [INFO] waiting for zones Thu Oct 30 20:30:39 2025: [libs]: edera: [INFO] got zone ZoneMetadata { domid: 3, uuid: 30782e65-f18d-4d5e-a37b-2acbdd67418d } Thu Oct 30 20:30:39 2025: [libs]: edera: [INFO] pushing handle for zone 30782e65-f18d-4d5e-a37b-2acbdd67418d Thu Oct 30 20:30:39 2025: [libs]: edera: [INFO] starting zone event pump for zone 30782e65-f18d-4d5e-a37b-2acbdd67418d Thu Oct 30 20:30:39 2025: [libs]: edera: [INFO] Listening for kernel events from zone 30782e65-f18d-4d5e-a37b-2acbdd67418d 20:30:45.734123070: Warning EDERA Event | time=20:30:45.734123070 zone_id=30782e65-f18d-4d5e-a37b-2acbdd67418d evt.type=open syscall.type=open evt.category=EC_SYSCALL evt.dir=< proc.exe=zone evt.args=| PT_FD 368| PT_FSPATH /proc/stat| PT_FLAGS32 0x00000801| PT_UINT32 0| PT_UINT32 20| PT_UINT64 4026532094| is_open=true 20:30:45.734187106: Warning EDERA Event | time=20:30:45.734187106 zone_id=30782e65-f18d-4d5e-a37b-2acbdd67418d evt.type=close syscall.type=close evt.category=EC_SYSCALL evt.dir=> proc.exe=zone evt.args=| PT_FD 368| is_open=false ``` Each event includes: - **zone_id** - The UUID of the zone that generated the event - **evt.type** - The syscall type (open, close, execve, etc.) - **proc.exe** - The process that made the syscall - **evt.args** - Parsed syscall arguments (file paths, FDs, flags, etc.) ## Available event fields The Edera plugin exposes [the same queryable fields on its zone events that Falco’s host events do](https://falco.org/docs/reference/rules/supported-fields/). Currently this includes all members of the following field classes - [`evt`](https://falco.org/docs/reference/rules/supported-fields/#field-class-evt) - [`evt (for system calls)`](https://falco.org/docs/reference/rules/supported-fields/#field-class-evt-for-system-calls) - [`process`](https://falco.org/docs/reference/rules/supported-fields/#field-class-process) - [`fd`](https://falco.org/docs/reference/rules/supported-fields/#field-class-fd) - [`fs.path`](https://falco.org/docs/reference/rules/supported-fields/#field-class-fs-path) - [`fdlist`](https://falco.org/docs/reference/rules/supported-fields/#field-class-fdlist) with the following exceptions: - Due to Falco plugin API limitations, fields that under Falco support multiple forms of argument-based indexing only support numeric indexes in the Edera plugin context (ex: `evt.arg[0]` is supported, `evt.arg.fd` is not). - Due to Falco plugin API limitations, `evt.rawarg` and `evt.rawres` are not supported (use `evt.arg` and `evt.res` instead) - `thread.cpu`, `thread.cpu.user`, and `thread.cpu.system` are not supported at this time. - `fd.containername` and `fd.containerdirectory` are not supported at this time. - `fd.name_changed` is not supported at this time. - The [`user`](https://falco.org/docs/reference/rules/supported-fields/#field-class-user) field class is not supported at this time. - The [`group`](https://falco.org/docs/reference/rules/supported-fields/#field-class-group) field class is not supported at this time. - Support for the [`container` field class](https://falco.org/docs/reference/rules/supported-fields/#field-class-container-plugin) is planned. The Edera plugin additionally exposes the following new, plugin-specific fields on its events: | Field | Description | | --- | --- | | `edera.zone.id` | UUID of the zone that generated the event | As with standard Falco host events, some field classes come from raw event data; others are enriched using the plugin’s internal thread and FD snapshot tables. ## Example rules With `mirror_host_syscalls: false`, zones emit the full set of Falco-supported syscalls but no rules are pre-configured. You write rules explicitly for the activity you want to detect inside zones. All zone rules use `source: edera_zone` and should include `evt.pluginname == "edera"` in their condition. The examples below cover common post-exploitation techniques. ### Detect credential harvesting via procfs Attackers who gain code execution inside a container often scrape `/proc/*/environ` to harvest secrets (API keys, tokens, database passwords) from neighboring processes. This is the technique used in attacks like [Leaky Vessels](https://www.docker.com/blog/docker-security-advisory-multiple-vulnerabilities-in-runc-buildkit-and-moby/). ```yaml - rule: Edera Proc Environ Read desc: > Detect reads of /proc/*/environ inside an Edera zone. Credential harvesting via procfs is a common post-exploitation technique for extracting secrets from neighboring workloads. source: edera_zone output: > Credential harvesting attempt in zone (zone_id=%edera.zone.id proc=%proc.exe file=%fd.name) priority: WARNING condition: > evt.pluginname == "edera" and evt.type in (open, openat) and fd.name glob /proc/*/environ ``` ### Detect reverse shells and suspicious network tools Attackers use tools like `nc` (netcat), `ncat`, or scripting languages to establish reverse shells back to a C2 server. Detecting these processes inside a zone catches lateral movement and exfiltration attempts. ```yaml - rule: Edera Reverse Shell Tool desc: > Detect execution of common reverse shell tools inside an Edera zone. Legitimate workloads rarely invoke netcat, socat, or similar tools. source: edera_zone output: > Reverse shell tool executed in zone (zone_id=%edera.zone.id proc=%proc.exe cmdline=%proc.cmdline) priority: CRITICAL condition: > evt.pluginname == "edera" and evt.type in (execve, execveat) and proc.name in (nc, ncat, netcat, socat, telnet) ``` ### Detect namespace escape attempts `nsenter` allows a process to enter another process’s namespaces—a well-known privilege escalation vector in containerized environments. Detecting it inside a zone catches breakout attempts early. ```yaml - rule: Edera Namespace Escape Attempt desc: > Detect nsenter execution inside an Edera zone. nsenter is commonly used in container escape and privilege escalation attacks to enter host or other container namespaces. source: edera_zone output: > Namespace escape attempt in zone (zone_id=%edera.zone.id proc=%proc.exe cmdline=%proc.cmdline) priority: CRITICAL condition: > evt.pluginname == "edera" and evt.type in (execve, execveat) and proc.name == nsenter ``` ### Detect sensitive file reads Attackers often read files like `/etc/shadow`, `/etc/passwd`, or application secrets to escalate access. This rule catches broad filesystem reconnaissance inside zones. ```yaml - rule: Edera Sensitive File Read desc: > Detect reads of sensitive system files inside an Edera zone, including credential stores and security-critical configuration. source: edera_zone output: > Sensitive file read in zone (zone_id=%edera.zone.id proc=%proc.exe file=%fd.name) priority: WARNING condition: > evt.pluginname == "edera" and evt.type in (open, openat) and (fd.name startswith /etc/shadow or fd.name startswith /etc/kubernetes or fd.name startswith /run/secrets) ``` ### Detect outbound network connections Unusual outbound connections from a zone may indicate data exfiltration or C2 communication. This rule logs all outbound network connections for audit. ```yaml - rule: Edera Outbound Connection desc: Detect outbound network connections from Edera zones source: edera_zone output: > Outbound connection from zone (zone_id=%edera.zone.id proc=%proc.exe dest=%fd.rip:%fd.rport proto=%fd.l4proto) priority: NOTICE condition: > evt.pluginname == "edera" and evt.type == connect and fd.type == ipv4 ``` ## Troubleshooting ### No events appearing #### Node-based troubleshooting **Check the Falco logs** for errors related to the Edera plugin: ```bash sudo falco -o "log_level=debug" 2>&1 | grep -i edera ``` **Verify the socket exists**: ```bash ls -l /var/lib/edera/protect/daemon.socket ``` **Confirm zones are running**: ```bash sudo protect zone list ``` #### Helm-based troubleshooting **Check the Falco pod logs** for errors related to the Edera plugin: ```bash kubectl logs -n falco -l app.kubernetes.io/name=falco -c falco | grep -i edera ``` **Verify the socket and plugin are mounted** in the Falco pod: ```bash # Get the Falco pod name FALCO_POD=$(kubectl get pods -n falco -l app.kubernetes.io/name=falco -o jsonpath='{.items[0].metadata.name}') # Check if daemon socket is mounted kubectl exec -n falco $FALCO_POD -c falco -- ls -l /var/lib/edera/protect/daemon.socket # Check if plugin library exists kubectl exec -n falco $FALCO_POD -c falco -- ls -l /var/lib/edera/protect/falco/libedera_falco_plugin.so ``` **Confirm zones are running** on the node (SSH to node or use kubectl debug): ```bash # Using kubectl debug kubectl debug node/ -it --image=busybox -- chroot /host protect zone list ``` **Verify the Helm values were applied**: ```bash helm get values falco -n falco ``` ### Plugin fails to load #### Node-based plugin loading **Check plugin file permissions**: ```bash ls -l /var/lib/edera/protect/falco/libedera_falco_plugin.so ``` The file should be readable by the user running Falco (typically root). **Verify Falco version compatibility**: ```bash falco --version ``` The Edera plugin requires Falco 0.41.0 or later. #### Helm-based plugin loading **Check if the hostPath volumes are correctly mounted**. The plugin and socket must exist on the **host node** at: - `/var/lib/edera/protect/falco/libedera_falco_plugin.so` - `/var/lib/edera/protect/daemon.socket` Verify these exist on your nodes using kubectl debug: ```bash kubectl debug node/ -it --image=busybox -- ls -l /host/var/lib/edera/protect/ ``` **Check Falco pod events** for mounting errors: ```bash kubectl describe pods -n falco -l app.kubernetes.io/name=falco ``` Look for errors related to volume mounts or plugin loading. **Verify the Falco image version**: ```bash kubectl get pods -n falco -l app.kubernetes.io/name=falco -o jsonpath='{.items[0].spec.containers[0].image}' ``` The Edera plugin requires Falco 0.41.0 or later. ### Plugin keeps reconnecting to zones If you see the plugin repeatedly logging reconnection messages for a zone every few seconds: ```bash [libs]: edera: [INFO] Listening for kernel events from zone ``` This indicates the connection to the zone is being re-established repeatedly. This can happen if: **The event stream connection is unstable** - Check the Edera daemon logs for any errors or connection issues: ```bash # For node-based installations sudo journalctl -u edera-protect -f # For Helm-based installations (check node logs) kubectl debug node/ -it --image=busybox -- chroot /host journalctl -u edera-protect -n 50 ``` **The zone is restarting or having issues** - Verify the zone/workload is running stably: ```bash # Check pod status kubectl get pod # Check pod events kubectl describe pod ``` If the plugin continuously reconnects and **no events appear**, this may indicate an issue with the event streaming mechanism. Contact Edera support with: - Falco logs showing the reconnection pattern - Edera daemon logs from the affected node - Zone/workload information ### Events stop streaming after CPU hotplug This is expected behavior, and similar to Falco’s behavior when hostside CPU hotplug events are detected. The plugin will automatically disconnect and reconnect to the zone where the hotplug event was detected to invalidate the zone’s thread cache, and then resume processing events. You should see log messages indicating the reconnection. ## Next steps - **Write custom rules** - Tailor Falco rules to your security policies and compliance requirements - **Integrate with SIEM** - Forward Falco alerts to your SIEM or logging platform (for example, Splunk, Elasticsearch) - **Explore Falco outputs** - Configure Falco to send alerts to Slack, PagerDuty, or other notification channels - **Review Falco docs** - Learn more about [Falco rules syntax](https://falco.org/docs/rules/) and best practices ## Summary You’ve successfully configured the Edera Falco plugin to monitor runtime activity in protected zones. By combining Edera’s hypervisor-based isolation with Falco’s eBPF-powered threat detection, you now have deep visibility into syscalls, file access, network connections, and process execution—all without compromising zone security. Happy threat hunting.