Falco modern eBPF or kernel module: when each driver fits
The Falco modern eBPF probe is the documented default and fits most deployments where the node kernel and your security policy allow eBPF programs to load. The kernel module is the choice when the modern eBPF probe cannot run on a given node, for example because the kernel is too old or lacks the features the probe needs, or because the node's configuration blocks it. The deciding conditions are the kernel version and distribution on each node pool, whether the nodes are ones you control or a managed Kubernetes service, and whether your hardening baseline permits the privileges each driver requires. The exact kernel, configuration and build requirements for each driver are not restated here, so confirm them in the Falco documentation for the release you deploy. Falco 0.45.1 was published on October 19, 2026, so check the driver guidance against that release line before you fix a driver choice.
On self-managed nodes, you can usually pick either driver after inspecting the kernel. On managed Kubernetes, the provider often restricts loading kernel modules, which makes the modern eBPF probe the practical route, but some node images and older kernels may not support it. Ask the provider which node images and kernel versions are offered, whether custom node images are allowed, and whether the security profile on those nodes permits the capabilities Falco needs. Treat any node pool you cannot inspect as unverified until a test confirms the driver loads and events arrive. Test each driver on the nodes you will actually run. Deploy Falco on a representative node from each pool with each candidate driver, trigger a few known events such as a shell spawned inside a container, and confirm the alerts reach your output. Record which driver loaded, any startup errors, and CPU and memory use under your normal workload. Repeat the test after every node image update or Falco upgrade, since a kernel change can move a node from working to unsupported without any change to Falco itself.
How the modern eBPF probe and kernel module compare
This table compares Falco's two kernel drivers on the factors that change the decision, from default status and privilege to managed node limits and staging tests. Read each row against your own node pools, and treat the Falco documentation as the authority for exact kernel and build requirements.
| Factor | Modern eBPF probe | Kernel module |
|---|---|---|
| Default status | Used by default in current Falco releases, built on the CO-RE paradigm | Documented alternative that must be selected explicitly |
| How the driver loads | Loaded as eBPF programs into the kernel, without compiling code on the node | Compiled against node kernel headers and inserted as a kernel module |
| Kernel and build dependencies | Depends on a kernel with the eBPF features Falco documents; confirm minimum kernel in the Falco docs | Depends on matching kernel headers and a successful build for each kernel version; confirm requirements in the Falco docs |
| Privilege needed on the node | Needs elevated capabilities to load eBPF programs; confirm the exact set for your Falco chart | Needs permission to insert kernel modules, a broader privilege on the node |
| Managed Kubernetes nodes | Often the only option where the provider blocks kernel module loading; check your provider's node image policy | May be blocked on managed node images; confirm with the provider before planning around it |
| Effort when node kernels change | Usually least effort, since no per-kernel build step is documented as required | Each kernel update may need a rebuild or a fresh module; plan rollouts around this step |
| Testing in a staging cluster | Test on a node pool with the same OS image and kernel as production before rollout | Test on a node with the exact kernel and headers used in production, since builds are kernel specific |
How the driver choice splits by node environment
Self-managed Linux nodes give you the most control. You choose the kernel, the boot image and the packages, so the modern eBPF probe is usually the starting point. It is Falco's default driver and it avoids building a kernel module for each kernel. The kernel module stays available if the eBPF probe cannot run on a particular kernel, so test both drivers on a node built from your standard image before you standardize.
- Kernel and headers: confirm the running kernel is supported for the driver you pick, and check whether your image includes the headers a module build needs.
- Driver setting: find how your install selects the driver and confirm that setting in the Falco documentation for the release you deploy, currently 0.45.1.
- Kernel upgrades: a kernel update can change which driver loads, so re-test at install time and after every kernel update.
- Privileges: verify that your host hardening allows the agent the privileges the chosen driver needs.
- Failure mode: if the driver does not load, Falco stops collecting system call events on that host, which can look like a quiet host. Monitor for missing events, not only for a running process.
Before you choose, run a test event on each driver on every node image you operate.
Managed Kubernetes node pools often limit what you can change on worker nodes. Some providers restrict kernel module loading, and some node images ship with a kernel you cannot rebuild. The modern eBPF probe is usually the starting point because it avoids loading a module, but it still depends on the kernel and image the provider supplies. Limits differ by provider, so confirm them in the provider's documentation and against Falco's current requirements before you commit.
- Node image: record the node OS image and kernel line for each pool and whether the provider upgrades them automatically.
- Module policy: ask in writing whether the provider permits kernel module loading on each pool at all.
- Pod privileges: check whether the provider's admission controls or Pod Security Standards allow the privileged or host-mounted settings the DaemonSet requires.
- Node upgrades: automatic image or Kubernetes upgrades can change the kernel under Falco, so schedule a validation after each pool upgrade.
- Failure mode: the Falco pod may stay in an error or crash loop on nodes where the driver cannot load, leaving those nodes unmonitored. Alert on the pod state so the gap is visible.
Validate Falco on one pool with the chosen driver before you roll it out to the rest.
Hardened and air-gapped hosts usually change kernels only through formal approval, so the approval record is part of the deliverable. The starting point is the driver that your approved kernel build supports. Test on a staging host built from the same image before you submit the change, because the approved build is the one that must work. Falco packages and any driver artifacts must also reach the host through your internal channel, which makes them part of the change.
- Approved kernel build: identify the exact kernel build your change process approves and test the driver against that build.
- Artifact provenance: take driver artifacts and Falco packages from your internal mirror and record their checksums in the change.
- Module signing: if your hosts enforce signed kernel modules, confirm the module is signed by a key the host already trusts before the window opens.
- Change record: document the driver, kernel build, test results and rollback steps so the approval matches what will run.
- Failure mode: if the driver fails at boot or after the change, the host may run without Falco coverage until the change is reverted. Define the rollback and the monitoring gap in advance.
Load the chosen driver on a staging host with the approved kernel and attach the result to the change ticket.
What each driver asks of the kernel and build
Falco needs a driver to see system calls, and the two options place different demands on the kernel, the build pipeline and the node. The four cards below cover what your team must verify, who usually owns each check, and what changes when the node image is patched.
Kernel version and feature support
The modern eBPF probe depends on kernel features that the kernel module does not need in the same way, so the first check is whether your node kernels expose what the probe requires. Confirm the current minimum kernel and feature requirements in the Falco driver documentation before you standardize on either driver. Record the exact kernel version for each node pool, because a mixed fleet can need different driver choices per pool. The platform team usually owns this check, using the output of the node inventory.
Build and packaging path
The kernel module must be built against the headers of the running kernel, so each kernel update can require a rebuild or a matching prebuilt artifact. The modern eBPF probe is built on the CO-RE approach and ships as part of the Falco install, which generally removes the per-kernel compile step. Ask the platform team whether your pipeline can produce a module for every kernel in use, and who signs off on the build artifact. Confirm the current build options with the Falco documentation.
Privileges and module loading on the node
Loading a kernel module is a privileged operation, and many managed Kubernetes node images restrict it or do not allow it at all. Check whether your node image permits module loading, whether Falco's pods can run with the privileges the driver needs, and whether your admission controls or Pod Security settings block them. The node image owner, often the cloud or platform team, decides these settings, so raise them before the driver choice is final. Document each privilege exception for the security team.
Portability across kernel updates
An OS image patch can move the kernel forward and invalidate a kernel module built for the previous version, which can silently stop event collection on affected nodes. The modern eBPF probe is less tied to an exact kernel build, but it still depends on the feature set of each kernel. Make driver health a monitored signal, test each new node image in a staging pool before rollout, and ask the node image owner for the patch schedule. Your change process should name who reruns the driver test after every patch.
How managed Kubernetes node limits change the driver decision
On many managed Kubernetes services, the provider restricts loading kernel modules and changing the node kernel, so the driver choice is often made for you before you compare features. A kernel module may be blocked outright on the node image the provider supplies, or it may only work if you build and maintain a custom node image, which then has to be rebuilt for each kernel the provider ships. Confirm with your provider whether module loading is permitted on your node pool type, whether custom node images are supported, and how the provider builds and publishes node images. Ask for the answer in writing, because the rules differ between provider managed node offerings and self-managed nodes in your own accounts.
The modern eBPF probe is the path most teams use to avoid node-level module loading, because it is built on the CO-RE paradigm and does not require compiling a kernel module against each node's kernel headers. It still depends on the node kernel supporting the eBPF features Falco needs, so a node image on an older kernel can block it just as a module restriction would. Check the kernel version on each node pool against Falco's driver documentation before you commit, and confirm that the provider's default image does not drop those kernel features in a later release.
Node pools also upgrade on their own schedule. Under the Kubernetes version skew policy, kube-apiserver is upgraded first, one minor version at a time, and kubelets may be up to three minor versions older than kube-apiserver. A node pool can therefore keep running an older kernel and kubelet for some time after the control plane moves on, and a provider node image replacement can change the kernel under a working driver without any change to your Falco configuration. Treat every node image change as a trigger to re-test the driver on a canary pool, confirm that Falco still loads and emits events for your rules, and keep the old image available for rollback until the new one passes.
How to test each driver on your own nodes
This sequence shows which Falco driver works on each node pool in your environment, using measured event coverage and resource use from your own staging nodes rather than general claims about kernels.
Inventory kernels and node images per pool
The platform team lists every node pool that will run Falco, recording the kernel version, OS image, container runtime and whether the managed Kubernetes provider lets you load kernel modules on those nodes. Include nodes that are updated automatically, since their kernel can change without a change request. The step is done when each pool has a row in a shared inventory with its kernel, OS image and provider restrictions, and someone other than the author has reviewed it.
Confirm driver requirements for the Falco release
The security engineer reads the driver requirements in the Falco documentation for the exact release you plan to deploy, currently 0.45.1 as published on October 19, 2026, and checks each inventoried kernel against the modern eBPF and kernel module prerequisites. Record which pools meet the modern eBPF requirements, which meet the kernel module requirements, and which meet neither. Confirm any build or header dependencies with your OS vendor, since the documentation may not cover your distribution. The step closes with a requirements matrix signed off for each pool.
Deploy the modern eBPF probe on staging
On a staging node pool that matches one production pool, the platform engineer deploys Falco with the modern eBPF probe as the driver, using the same Falco version, rules and Falcosidekick or output configuration planned for production. Confirm the driver loads and the Falco pods report healthy on every node in the pool. The step is done when the driver status is verified on each staging node and the deployment manifest is saved in version control.
Record rule firings on test activity
The security engineer runs a fixed set of test activities on the staging nodes, such as spawning a shell in a container, writing to a sensitive path and making an unexpected outbound connection, and records which rules fire and which events reach each output. Use activity that is known to be benign and labeled as a test so the results can be repeated. Keep the test script in the repository. The step closes with a table of test cases, expected rules and observed alerts for the modern eBPF probe.
Repeat the test with the kernel module
Where the provider and your change policy permit loading kernel modules, the engineer builds or installs the kernel module on a comparable node, runs the same test script and records the same rule and output results. If loading kernel modules is restricted on managed nodes, record that as the outcome for that pool and do not substitute a node that differs in kernel or OS. The step is done when the kernel module results are recorded in the same table, or the restriction is documented with the provider's policy reference.
Compare event coverage and resource use
The team compares the two result sets side by side, looking for test cases that fired under one driver and not the other, differences in alert fields and any gaps in events the rules depend on. Measure CPU and memory of the Falco pods under the same load for both drivers using your own monitoring, and record the figures with the workload used. The step closes with a comparison summary that names every gap and states whether it is acceptable for the pool's risk profile.
Verify the driver survives node updates
The platform team triggers a node image or kernel update on the staging pool, using the same mechanism the provider uses in production, then checks that Falco restarts with its chosen driver and that the test script still produces the same alerts. For kernel module deployments, also confirm the module rebuilds or reloads after the kernel change. The step is done when the post-update run matches the pre-update results, or the failure is logged with a fix owner.
Record the approved driver per pool
The security lead and platform owner review the results and record one approved driver for each node pool in the configuration repository, along with the Falco version, kernel and OS image it was tested on. Note the reference point: a Wazuh integration documents Falco on K3s using the modern eBPF driver, which you can compare against your own K3s or managed results, though your environment still needs its own test. The step closes when the approval record is merged and linked from the Falco deployment documentation.
Upgrades, rollback and monitoring for each driver
This table compares what your team must maintain over time for the modern eBPF probe and the kernel module. Read each row as a recurring task, and confirm the driver support matrix for your Falco release before any rollout, since each driver follows its own upgrade path.
| Operating task | Modern eBPF probe | Kernel module |
|---|---|---|
| Upgrade path | Falco and the probe are versioned together in the Falco release, so each Falco upgrade needs a check that the probe build supports your kernels. Confirm the driver support for Falco 0.45.1 in the Falco documentation before rollout. | The module is built or loaded against a specific kernel, so each Falco upgrade and each kernel change may require a matching module build. Confirm the module build path for your Falco version and distribution. |
| Node kernel patching | Kernel patches that stay within a supported kernel version usually need no driver change, but confirm this against the documented kernel requirements for your Falco release. | Every kernel patch can break the module load until a matching build is available, so schedule patching with a rebuild or a validation step on a canary node. |
| Rollback | Roll back by reverting the Falco chart or package version and confirming the probe loads on the previous release. Keep the previous version pinned in your deployment manifests. | Rollback may require the previous module build as well as the previous Falco version. Store known-good module artifacts alongside Falco release artifacts so both can be restored together. |
| Load failure signals | Look for driver load errors in the Falco pod or service logs at startup and in health checks that confirm events are flowing. A silent probe failure can show as no alerts, so test with a known trigger. | Look for module insertion or build errors in node logs and Falco startup logs. Monitor the kernel log for module load failures after a reboot or patch window. |
| Who owns the node image | Platform or cluster teams own the node image and kernel, and security engineering owns the Falco version and rule set. Agree in writing who approves a kernel change that could affect the probe. | Node image owners must include module build or signing steps in the image pipeline, which usually makes the platform team the primary owner. Security must approve any change to the module build chain. |
| Skills to diagnose a failed probe | Staff need to read Falco startup logs, check kernel version and BTF availability, and understand the CO-RE build model. Confirm the minimum kernel and BTF requirements with the Falco documentation. | Staff need kernel module tooling, build toolchain knowledge, kernel header management and experience with module signing where Secure Boot is enabled. Confirm these needs with your distribution's guidance. |
| Managed node constraints | Often the lower-friction option on managed nodes where kernel module loading is restricted, but only if the node kernel meets the probe requirements. Confirm with your provider whether the required kernel features are available. | Often requires provider support or a custom node image before it can load on managed nodes. Confirm with the provider whether module loading is permitted and who maintains any custom image. |
Questions teams ask before choosing a Falco driver
Is the modern eBPF probe the default Falco driver?
Yes. Falco's documentation describes the modern eBPF probe, built on the CO-RE paradigm, as the default driver, with a kernel module as the other documented option. The default still needs checking in your environment because the driver that works depends on what each node runs. Confirm the driver setting in your deployment configuration for every node pool, since clusters often mix node images. Also confirm the Falco version you plan to deploy. The current release is 0.45.1, published on October 19, 2026, according to the Falco GitHub releases page, so check its driver notes before you standardize on a configuration.
Can managed Kubernetes services load the Falco kernel module?
It depends on the provider, the node image and the account settings, so confirm it in writing before you design around it. Managed node pools often restrict loading kernel modules or lock the node operating system, which is why many teams evaluate the modern eBPF probe first. Ask the provider whether custom kernel modules can be loaded on your node image, whether you can use a customizable node image, and whether the provider supports the driver you plan to run. If the answer is no for some pools, you can run the modern eBPF probe there, move those workloads to self-managed nodes, or use a different runtime security tool for those pools.
What does the platform team need to run a Falco driver?
The platform team owns the node images, the Falco deployment and the upgrade path, while the security team usually owns rules and alert routing. Day-to-day work includes confirming kernel support for each node pool, deploying the driver through your chosen method, checking that events arrive from every node, and upgrading Falco alongside node operating system patches. Kernel patches can change driver behavior, so keep a test cluster that matches production and schedule driver changes in change windows. Staff need working knowledge of Linux kernels, Kubernetes DaemonSets and RBAC, and the Falco rule language.
How long does testing a Falco driver take, and what drives the effort?
No fixed duration applies to every environment, because the effort follows fleet diversity. The main drivers are the number of distinct kernel versions and node images, the number of cluster types, whether you have a lab that matches production, and how many detection rules you validate against realistic workloads. A useful test measures event coverage, CPU overhead and whether expected rules fire on each node pool with each driver. Before you commit to a timeline, ask for a written list of node images to be tested, the rules to be validated and the acceptance criteria. Those three items determine most of the schedule.
Do I need an implementation partner to choose and test a driver?
Not always. A team with solid Linux and Kubernetes skills can run a driver comparison internally, especially on a small, uniform fleet. A partner becomes more useful when kernels vary widely, when the environment is air-gapped or heavily regulated, or when staff capacity is limited during rollout. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Decide based on whether your team can cover node images, rule tuning and upgrades over time.
What should I ask for in a scoped quote for a Falco deployment?
Ask for a scope that names the clusters and node pools covered, the driver chosen for each pool and the reason, the kernel and operating system versions in scope, the deployment method, the rule set and tuning work, the alert destination, the test method and acceptance criteria, and the documentation you will receive. Also ask which items are one-time work and which recur, such as upgrades, rule maintenance or support retainers. DeployOpen does not publish a price list, and a quote follows from the written scope, so the more precisely the scope lists these items, the more comparable the quotes will be.
How DeployOpen scopes and delivers Falco driver work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so Falco runs on the nodes you operate. Driver choice is settled by testing the modern eBPF probe and the kernel module on representative nodes before anything is rolled out.
How we scope
- Inventory node operating systems, kernel versions and whether managed node pools restrict loading kernel modules.
- Agree in writing which driver each node group will test, and which fallback applies if a test fails.
- Define which event sources, rules and alert outputs are in scope, including any Falcosidekick forwarding.
How we build
- Deploy Falco on a staging node pool and record which driver loads, with its build or probe method, on each node image.
- Run the same rule set under both drivers and compare alert fidelity, dropped events and resource use on your workloads.
- Harden the Falco configuration and daemonset permissions to the minimum your chosen driver needs.
How we hand over
- Deliver a driver decision record covering kernel versions, test results and the conditions that would trigger a retest.
- Document the upgrade steps for kernel patches, node image changes and Falco version updates on your nodes.
- Provide runbooks for switching drivers, with rollback steps agreed and tested before production use.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped to your environment.
- Ask for a quote built from the written scope, covering node count, test rounds and handover documentation.
