Why runtime Kubernetes detection needs its own design in regulated environments
Falco detects runtime behavior on each Kubernetes node, but it does not stop anything by itself, so the response path has to be designed separately. A regulated organization running self-hosted Kubernetes that holds ePHI or customer financial data needs visibility into what containers do at the kernel level, which host EDR on the node does not give it on its own. Falco uses the modern eBPF driver by default, with a kernel module as the alternative, and turns custom rules into alerts. The Falco documentation describes alerting and forwarding to other components for action, not blocking. The short answer on platforms is therefore three roles: Falco for detection, Wazuh or another SIEM for storage and correlation, and a response workflow owned by the client's own SOC.
Falco is licensed under Apache-2.0, and release 0.45.1 was published on October 19, 2026. It became a CNCF Graduated project on February 29, 2024, which matters for procurement teams asking about project governance. Confirm with your own security team which Falco version and driver your cluster distribution supports, since kernel compatibility decides whether the eBPF probe loads on a given node image. Also confirm who owns Falco rule changes, because a tuned ruleset is part of the control evidence an assessor will ask about.
Alert delivery is the step most often underspecified. Falco can write to standard output, a file, syslog, a spawned program or an HTTP(S) endpoint, and Falcosidekick can fan events out to chat, ticketing and other channels. Before go-live, decide which events page a person, which are queued for daily review, and which open a case in the ticketing system, and assign an owner for each path. A detection that reaches a log but no one is accountable for acting on it will not satisfy an audit trail or an incident response plan, whatever the rule says.
Which regulatory requirements shape Kubernetes runtime detection
This table maps two US requirements, HIPAA audit controls and FTC Safeguards logging of authorized user activity, to specific runtime detection design choices for a Kubernetes cluster. Read each row as a design decision to make with your assessor and security team before rules are written. The main takeaway is that a regulation rarely dictates a Falco rule directly, but it does determine scope, the events that must be recorded, how long they are kept and whether each event can be tied to a person.
| Requirement or risk | What it asks for in runtime design | Evidence an assessor will expect |
|---|---|---|
| Audit controls (45 CFR 164.312) | Scope Falco to every namespace and node that stores, processes or transmits ePHI, including the nodes hosting EHR components and their supporting services | Written scope list of namespaces and nodes, with the reason each is in or out |
| Unique user identification (45 CFR 164.312) | Link each shell session, exec call and privilege change to a named identity from the Kubernetes authentication method, not to a shared service account | Sample alerts showing the authenticated user, the pod and the time, traced back to the identity provider |
| Logging of authorized user activity (16 CFR 314.4) | Write Falco rules for interactive shell access in pods, kubectl exec and attach, and privilege escalation such as privileged containers or host mounts | Rule inventory mapped to each activity type, with test results showing each rule fires on a controlled event |
| Retention of alerts | Forward Falco events from each node to Wazuh or the SIEM and set retention so records outlive the investigation window; confirm the period with counsel and your own policy | Retention settings in the storage tier, plus a documented retrieval test for a sample date range |
| Secrets stored unencrypted in etcd by default | Add rules for reads of secret-mounted paths inside pods, and confirm etcd encryption at rest is enabled separately, since Falco does not replace it | Configuration evidence for etcd encryption, and alerts showing access to mounted secret files |
| Prompt detection of misuse | Route high-severity Falco alerts to a response path with a named owner, because Falco alerts but the documentation does not describe it blocking activity | Runbook with escalation steps, and records showing response time for test alerts |
| Rule tuning and false positives | Tune rules per namespace so routine maintenance jobs do not drown out real access events, and record each change | Change log for rule edits with approver and reason, plus periodic review notes |
Which open-source platforms fit Kubernetes runtime detection and why
Runtime detection for Kubernetes usually combines a node-level sensor, a place to store and search alerts, and a response path that is separate from the detector. The cards below cover the components that fill those roles and the checks to make before committing to one.
Falco on each node
Falco is the runtime sensor in this design. It runs on every node and, by default, uses the modern eBPF probe, with a kernel module available as an alternative. Custom rules cover shell access in containers and privilege escalation. Confirm that your node operating systems and kernel versions support the driver you choose, and test rules against your own workloads before relying on alert volume.
Falcosidekick fan-out
Falco only detects and alerts. It does not block activity. Falcosidekick forwards events to many destinations, so a single detection can reach the SIEM, chat channels and the response tooling. Each output adds a delivery path that needs its own monitoring, retry behavior and access control, so decide which destinations are authoritative for evidence.
Falco plugins for cloud and identity events
Falco plugins extend detection beyond system calls. Documented sources include Kubernetes audit logs, AWS CloudTrail and Okta. Use these when a question spans the control plane and the workload, such as a privileged role change followed by a suspicious pod start. Confirm which plugins your Falco version supports and which fields they expose before writing rules that depend on them.
Wazuh as the storage and dashboard layer
Wazuh receives Falco output through a Wazuh agent that reads the JSON file Falco writes, then applies Wazuh rules. Wazuh is licensed under GPL-2.0, and its indexer stores alerts while its dashboard includes prebuilt views for HIPAA and NIST 800-53. The documented integration covers K3s with the modern eBPF driver, so confirm that your distribution and driver match before planning on it.
Existing SIEM as the destination
If your organization already runs a SIEM, Falco events can usually go there directly through Falcosidekick or syslog, and Wazuh becomes optional. The question is whether the SIEM can parse Falco's JSON fields, keep the container and namespace context, and retain events for the period your auditors expect. Agree on field mapping and retention with the SIEM owner before the first rule goes live.
Kubernetes audit logs as a second source
Kubernetes audit logs record requests to the API server, such as who created a privileged pod or read a Secret. They complement Falco because they show intent at the control plane, while Falco shows behavior inside the container. Audit logging must be enabled and sent off the cluster, and its volume needs sizing. Confirm your provider's audit policy options with your platform team.
Shuffle for response automation
Shuffle is a SOAR platform licensed under AGPL-3.0 that can take a Falco alert and run enrichment or response steps, such as opening a ticket or isolating a workload through an approved API. Keep the response path separate from the detector so that a failure in one does not hide the other. AGPL-3.0 obligations apply if you modify and offer Shuffle to others, so have legal review that before rollout.
How a Falco rollout on regulated clusters progresses
The sequence moves from an inventory of clusters and nodes to tuned detection, routed alerts, a named response path and a review cycle, so each phase leaves evidence that the next phase depends on. Done in order, the rollout ends with alerts that someone is accountable for and that an assessor can trace.
Inventory clusters, nodes and kernel support
The platform team lists every cluster, its Kubernetes distribution and version, node operating systems, kernel versions and container runtimes, and records which clusters are managed by a vendor and which by your staff. Falco's modern eBPF driver is the default, so the team confirms kernel support on each node pool before anything is installed. Done means a signed-off inventory that names the owner of each cluster and flags nodes that need a kernel change or a different driver. Ask your Kubernetes distribution vendor which Kubernetes minor version each cluster runs and when its support ends, since Kubernetes 1.37 is end of life on October 28, 2027.
Deploy Falco in monitor mode with the eBPF driver
The team installs Falco on a non-production cluster first, using the modern eBPF driver, then on production nodes with the default rule set left unchanged. Falco only alerts in this phase, so the workloads are not affected while the team measures what fires. Done means every target node reports events, the Falco version and driver are recorded in the change record, and the baseline volume of alerts per workload is captured for the tuning phase.
Tune shell and privilege escalation rules
Security engineers review the baseline alerts with the application owners and write custom rules for shell access into containers and for privilege escalation, such as writes to sensitive paths or processes gaining capabilities they should not have. Each exception is tied to a named workload, a namespace and a reason, so an auditor can see why it was allowed. Done means the rule set is in version control, each exception has an owner and a review date, and a test pod that performs a forbidden action produces the expected alert.
Route events to Wazuh or the SIEM
Falco writes JSON events to a file or sends them over HTTP(S), and Falcosidekick can forward them to other destinations. The team connects the output to a Wazuh agent on a K3s or other supported node, or to the central SIEM, then writes decoders and rules so each alert carries cluster, namespace, pod and image fields. The retention decision is made here: the team records how long raw Falco events and correlated alerts are kept, where they are stored and who can read them. Done means a test alert appears in the analysis platform with the expected fields and a documented retention period.
Define the response runbook and alert owners
Falco detects and alerts but does not block activity, so the response path must be designed separately. The team agrees which alerts page a person, which open a ticket, and which trigger a containment step such as isolating a pod or cordoning a node, and who is authorized to run each step. Where automation is used, the playbook is written and tested before it is switched on. Done means a runbook exists for each alert class, the on-call roster covers it, and a tabletop exercise has walked through at least one shell-access alert from detection to closure.
Capture evidence for the assessment file
The compliance lead collects the artifacts an assessor will ask for: the inventory, the change records for installation and rule changes, the rule repository history, sample alerts with their handling records, retention settings and access reviews for the alert platform. These are mapped to the control objectives in scope, such as audit controls for systems that handle sensitive data. Done means an evidence index exists that points to each artifact, and the team has confirmed with the assessor which formats they accept.
Set a review cadence tied to upgrade cycles
Falco releases, Wazuh patch releases and Kubernetes minor releases each change what the detection depends on, so the team schedules a recurring review that checks rule changes, driver compatibility and alert volumes against the Kubernetes version skew rules and support dates. Kubernetes minor versions are supported for a limited period, so Falco and node kernels are re-tested before each cluster upgrade. Done means a dated calendar of reviews exists, each upgrade has a Falco compatibility check in its change record, and the tuning backlog is reviewed with the application owners.
Choosing a deployment pattern by cluster type and constraint
In a managed service, the provider runs the control plane and often controls the node image, so you may not be able to load a kernel module or change the host operating system. Falco's modern eBPF probe is the option to plan around, because it is the default driver and does not require building a kernel module against each node kernel. Whether it loads depends on the node operating system and kernel version, and on whether the provider allows the privileged access Falco needs on each node. Falco typically runs as a DaemonSet, one pod per node, and forwards events to Wazuh through a file read by an agent or to the SIEM through Falcosidekick.
- Node image control: Confirm whether you can use a custom node image or must accept the provider's default, since that decides which kernels you get.
- Driver support: Confirm that the modern eBPF probe is supported on your node pools, and test it on each node pool version before rollout.
- Privileges: Confirm whether the provider's admission controls or pod security settings allow the DaemonSet's host-level access.
- Audit and plugin sources: Plan for Kubernetes audit logs and cloud audit trails as separate sources, and confirm access to the control plane logs with the provider.
- Upgrades: Confirm how the provider rolls node upgrades, so Falco is redeployed and its rules stay in place after each change.
Before you commit, confirm the kernel version, driver support and privileged pod policy in writing with the provider, because these are the points most likely to change without notice.
On a self-hosted cluster built with kubeadm, you control the operating system, the kernel and the node images, so the driver decision is yours. The modern eBPF probe is still the default, but you can test a kernel module where the kernel does not suit eBPF. The control plane layout affects the design too. A stacked topology runs etcd on the control plane nodes, while an external etcd cluster separates them. Falco runs on worker and control plane nodes alike, so it must be scheduled on every node where you need coverage, including tainted control plane nodes.
- Driver choice: Standardize the kernel version on each node pool and test the modern eBPF probe against it before rollout.
- Control plane coverage: Confirm that the DaemonSet tolerates control plane taints, so the nodes running kube-apiserver and etcd are monitored.
- Stacked or external etcd: Stacked etcd shares a failure domain with the control plane, while an external cluster adds nodes to monitor and to back up. Plan Falco coverage for both.
- Event path: Decide whether events go to a file that the Wazuh agent reads, to Falcosidekick, or to a syslog collector, and size the storage for each path.
- Hardening: Confirm that the cluster's authentication settings and the Secrets encryption configuration are in place, since Falco alerts are only as useful as the audit context around them.
Confirm the kernel versions per node pool, the taints on control plane nodes and the etcd topology with your platform team, since each one changes where Falco must run.
On an air-gapped cluster, nodes have no route to public registries or update servers, so Falco's container images, driver artifacts, rule sets and plugins must arrive by approved media transfer. This affects every update, not only the first install. The kernel version on each node is fixed for long periods, so the driver must be validated against that kernel before it enters the enclave. Rule updates need the same review as any change to detection content, and the update cycle should be planned around the transfer process and the change control that governs it.
- Offline artifacts: Build an internal registry and an artifact bundle for Falco, the driver and the Falcosidekick images, and record the hash of each file.
- Rule updates: Plan a documented process for importing new rules, testing them in a staging cluster and approving them before they reach production nodes.
- Driver validation: Test the modern eBPF probe or kernel module against each kernel in the enclave, since kernel updates are slower there.
- Local event routing: Keep event sinks inside the enclave, such as a local Wazuh deployment or SIEM, and confirm that no outbound calls are needed.
- Plugin sources: Confirm which plugins, such as Kubernetes audit logs, can run without external services.
Confirm with your security and platform teams which media transfer process applies, how long an approved update takes, and whether the chosen driver is supported on each kernel in the enclave.
Evidence auditors and regulators ask for from runtime detection
This table lists the records a runtime detection program can produce, the component that generates each one, and what an assessor will want to see. Read it as a checklist for designing retention and access from the start. DeployOpen prepares this evidence, but auditors, certification bodies and regulators draw the conclusions about whether it is sufficient.
| Evidence item | Produced by | What to confirm or retain |
|---|---|---|
| Rule set version history | Git repository holding Falco rule files, reviewed through pull requests | Versioned rule files tied to the Falco version in use, with the date each change took effect and who approved it |
| Alert logs with timestamps, pod and namespace context | Falco with the modern eBPF driver, written to a file, stdout or syslog | Kubernetes metadata fields enabled in the rules output, retained for the period your framework requires, with clock sync evidence |
| Forwarding records from Falcosidekick or the Wazuh agent | Falcosidekick outputs or the Wazuh agent reading the Falco JSON file | Delivery logs showing each alert reached the SIEM or Wazuh indexer, and gaps or retries during outages |
| Alert triage tickets showing a response path | Ticketing system or Shuffle workflow linked to Wazuh alerts | Assignee, triage decision, containment steps taken on the pod or node, and closure reason for each alert |
| Tuning change records | Rule review process and Wazuh rule or decoder change history | Before and after rule logic, the alert volume that prompted the change, and the approver for suppressions or exceptions |
| Access records for who can change rules | Kubernetes RBAC on the Falco namespace, Git platform access logs and Wazuh user audit records | Named accounts with rights to edit rules or deploy the Falco DaemonSet, reviewed on a set schedule |
| Cluster and node coverage inventory | Wazuh agent inventory and Kubernetes node list | Proof that every node in scope runs Falco and a reporting agent, with exceptions documented and approved |
What do buyers ask before running Falco on regulated Kubernetes?
What drives the cost of running Falco on Kubernetes?
The cost is driven by how much you monitor and how much people spend tuning it. Node count and cluster count set the number of Falco deployments, and the Falco project's open-source license means there is no per-node license fee for Falco itself. The recurring costs are the servers and storage for the SIEM or Wazuh indexer that receives events, the engineering time to write and tune rules, and the staff who triage alerts. Ask any implementation partner for a quote that separates one-time work (installation, rule baseline, integration) from recurring work (rule maintenance, upgrades, on-call triage), and for the event volume assumptions behind the storage estimate.
How long does it take to reach a first production baseline with Falco?
The time depends on the number of clusters, how much of the default rule set you adopt, and how quickly your change process can approve a node-level agent. A baseline is reached when Falco runs on every target node, alerts flow into the SIEM or Wazuh, and the team has reviewed the first weeks of noise and adjusted rules. Most engagements are fixed-scope, so the timeline is agreed in writing before work starts. Ask the partner which milestones are included in that timeline and which depend on your approvals and change windows.
What does the client need to provide for a Falco deployment?
You need to provide access to the clusters and nodes, a sponsor who can approve privileged DaemonSet changes, and change windows that match your production freeze rules. On the detection side, you need named SOC runbooks for each alert category, a destination for events (Wazuh, your SIEM or a file pipeline), and an owner for rule approvals. Confirm with your Kubernetes platform team whether the nodes run a kernel that supports the modern eBPF driver, since the kernel module is the fallback. Ask the partner for a written list of prerequisites before scope is signed.
Can our internal teams run Falco and its alert pipeline themselves?
Yes, many teams run Falco in-house, but the work sits in three places: operating the Falco DaemonSet, maintaining rules, and keeping the alert path to the SIEM working. Platform engineers usually handle deployment and upgrades, while security engineers own rules and triage. A partner can build the initial rule set, document it and train your staff, and then either hand over or retain ongoing support. Ask what skills your team already has in Kubernetes internals and detection engineering before deciding between full ownership and a retainer.
Does Falco block attacks in Kubernetes or only alert on them?
Falco detects and alerts; it does not block activity. The Falco documentation describes alerts being forwarded to other components to take action, and it does not describe Falco itself stopping a process or container. That means a detection needs a separate response path, such as a Wazuh active response, a SOAR playbook from Shuffle, or a runbook that a responder executes by hand. Decide before go-live which alerts can trigger automatic containment and which need a human decision, because automatic actions on production pods carry their own outage risk.
How are Falco and Wazuh versions kept current?
Version currency is an ongoing task with its own schedule. Falco 0.45.1 was published on October 19, 2026, according to the Falco releases page, and Wazuh 4.14.9 was released on 14 October 2026 per the Wazuh release notes. Wazuh shipped 4.14 patch releases on six dates in 2026, roughly one every one to two months, so patch planning should assume regular cycles. Kubernetes also moves on its own cadence, with about three minor releases a year, and Falco must be tested against each cluster version. Ask the partner how they test upgrades in a staging cluster, how rules are versioned and who signs off on each change.
Which compliance evidence does a Falco deployment support?
Falco by itself does not satisfy a framework, but its alerts and their handling can support audit controls. For HIPAA, the Security Rule at 45 CFR 164.312 calls for audit controls that record and examine activity in systems containing ePHI. For the FTC Safeguards Rule at 16 CFR 314.4, covered institutions must monitor and log authorized user activity. Falco logs, Wazuh alerts and the response records together can show this monitoring. Confirm with your auditor which evidence they will accept, since DeployOpen prepares controls and evidence but does not issue audit reports or certifications.
How much does Kubernetes version skew affect Falco planning?
Version skew matters because the Kubernetes version skew policy requires kube-apiserver to be upgraded one minor version at a time, and kubelets may be up to three minor versions older than the API server. Falco runs on the nodes, so cluster upgrades can change the kernel, container runtime and kubelet behavior that Falco depends on. The three most recent minor releases are maintained, so plan to retest Falco after each cluster upgrade. Ask your partner to include a retest of the driver and rule set in every cluster upgrade change record.
Questions to put to an implementation partner for Kubernetes runtime detection
Start with the kernel. Falco's default driver is the modern eBPF probe, built on the CO-RE paradigm, with a kernel module as the alternative, so ask the partner which driver they will deploy on each node pool and why. Ask them to confirm, in writing, that the eBPF probe is supported on your exact kernel versions and distributions, including the managed node images your Kubernetes provider uses, and what they will do if a node image falls outside that set. Ask who owns kernel and node image changes, because a routine node upgrade can break the probe without anyone touching Falco. Also ask how they will handle the Kubernetes versions you run, since the project supports only the three most recent minor releases and your cluster will move through them.
Next, ask who writes and tunes the rules. A default ruleset that fires on normal database or CI activity will train your team to ignore alerts, so ask the partner for their tuning method: how a rule is proposed, tested against recorded events, approved by your security owner and versioned. Ask how events reach Wazuh or your SIEM. The Wazuh integration reads JSON events from a file through a Wazuh agent, so ask what happens when that file grows faster than it is read, when the agent loses its connection to the manager, or when the SIEM is down. Ask how Falcosidekick or equivalent forwarding is buffered and monitored, and what the partner will alert on when event flow stops. Ask them to state the evidence they will retain for each alert and for how long.
Finally, ask how detection stays separate from response. Falco documents alerting and forwarding of events for other components to act on, and it does not describe itself blocking activity, so ask which component will act on a shell-in-container or privilege escalation alert, who approves that action and whether any automated step can disrupt a production workload. Then ask for the written deliverables: the architecture, the driver and node compatibility matrix, the rule set with change log, runbooks, test results and handover. Confirm that the engagement is fixed-scope with a written statement of work, and ask what a retainer covers for Falco and Wazuh upgrades, rule updates and continuous validation, and how an upgrade is tested before it reaches production clusters.
How DeployOpen scopes and supports Falco on your clusters
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Kubernetes clusters in their cloud accounts or data centers. For Falco, that means agreeing in writing which clusters, rules, event paths and response owners are in scope before any work starts.
How we scope
- Inventory clusters, node pools, Kubernetes distributions and whether the eBPF driver is supported on each node image.
- Agree which Falco rules, such as shell access and privilege escalation, are in scope and who tunes them.
- Define where alerts go, whether Wazuh, the SIEM or another channel, and who owns triage and response.
How we build
- Deploy Falco on each node with the modern eBPF driver, with the kernel module documented as the alternative.
- Configure event output to a file, syslog or HTTP(S) endpoint and connect Falcosidekick where it is in scope.
- Integrate Falco events with Wazuh rules through a file read by a Wazuh agent, and test each alert path end to end.
How we hand over
- Document the Falco configuration, rule set, driver choice, alert routing and known detection gaps for your team.
- Provide a runbook that separates detection from response, so alerts trigger a defined human or automated action.
- Deliver test evidence showing which simulated container events generated which alerts, for your audit file.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, Falco and Wazuh upgrades and continuous testing are available as a retainer.
- Confirm with us during scoping how rule tuning, version upgrades and cluster changes will be handled after handover.
