Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 0 additions & 5 deletions .github/workflows/ci-code.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -4,11 +4,6 @@ on:
pull_request:
branches:
- main
paths:
- src/**
- Cargo.*
- rust-toolchain.toml
- .github/workflows/ci-code.yaml

permissions:
contents: read # Default token to read
Expand Down
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ Currently, we implement:
- The `base` plugin: This is the core `EderaPlugin`, and it maintains state to all the capability plugins.
- The `source` plugin. This plugin capability is responsible for talking to a running Edera daemon over `/var/lib/edera/protect/daemon.socket`, and watching for Edera zones. When a zone is discovered, the `source` plugin sends a message to the zone over the Edera IDM channel, asking the zone to begin streaming syscall events from the local zone kernel, encoded in [`libscap`'s binary format](https://falco.org/docs/concepts/event-sources/kernel/architecture/), back to it over the same channel. The zone replies with a snapshot of its local process state, including all current threads and their open file descriptors, and the plugin begins maintaining internal state for that zone by combining that initial state with the ongoing syscall events it sees. See [libscap-rs](../libscap-rs) for details on how these syscall events and initial state snapshots are scraped in-zone. Note that the state tracking is invalidated if a zone undergoes a CPU hotplug event - this is a core Falco limitation that the Edera plugin also shares. Falco will terminate if a CPU hotplug event is detected, but in our case, if a CPU hotplug event is detected, we simply disconnect from the zone and reconnect, reseeding the state, and carry on capturing.
- The `parse` plugin. The `parse` plugin is responsible for hydrating the raw `scap`-encoded events into internal plugin state, for consumption by plugins later on in the chain.
- The `extract` plugin. The `extract` plugin is responsible for exposing the list of valid "queryable properties" about each event and its context to the Falco rules engine. The goal is to expose analogs for every field that "regular Falco" would expose on host-generated syscall events. See https://docs.edera.dev/guides/observability/falco-integration/#available-event-fields for the currently-supported list.
- The `extract` plugin. The `extract` plugin is responsible for exposing the list of valid "queryable properties" about each event and its context to the Falco rules engine. The goal is to expose analogs for every field that "regular Falco" would expose on host-generated syscall events, without extra scoping, such that existing hostside Falco rules already in use can be trivially retargeted to alert on Edera zone events without significant rewrites. See https://docs.edera.dev/guides/observability/falco-integration/#available-event-fields for the currently-supported list.


## Usage and installation
Expand Down
Loading