Open source SIEM for Kubernetes and cloud workloads

Why an open source SIEM for Kubernetes and cloud workloads needs a different design

If your regulated workloads run in containers and cloud accounts, a SIEM built only for servers will miss most of what matters. The usual open source base is Wazuh, with Falco adding runtime events from inside clusters and cloud provider logs such as AWS CloudTrail feeding the same pipeline. The SIEM should run outside the clusters it watches, on infrastructure that does not depend on the cluster staying healthy, so that an attacker who compromises a node or a namespace cannot also silence the evidence. Wazuh's server, indexer and dashboard are the components you would place there, with agents or log forwarders on the nodes and the control plane feeding in from outside.

Two properties of this environment change the design. First, pods are short-lived. A workload may exist for minutes, so an agent-based model that waits for a host to check in can lose the context of a container that was replaced before anyone looked. Collection has to ship events as they occur, and alert rules must identify workloads by labels, namespaces and image names rather than by host name or fixed IP. Second, much of the security-relevant record sits in control plane logs, not on the workers. Kubernetes audit logs record requests to the API server, and Kubernetes authenticates users outside the API itself through client certificates, bearer tokens or an authenticating proxy, so the identity behind a request may appear only in the audit trail.

Before you select components, confirm three things with your platform team: which Kubernetes audit policy levels are enabled and where those logs are written, whether Falco can run with the modern eBPF driver on your node operating systems, and which cloud accounts and identity providers must feed the SIEM. Each answer changes ingest volume and alert noise, which is why the cluster design and the SIEM design should be settled together rather than in sequence.

Requirements a cluster-aware SIEM must meet and where they come from

This table maps each requirement that a SIEM watching Kubernetes and cloud workloads must satisfy to its origin, the build work it creates, and where implementations usually fall short. Read each row as a question to answer before choosing sources and detection content. The main takeaway is that the SIEM itself, and the people who can query it, become regulated systems in their own right.

Requirement	Where it comes from	What it means for the build	Where it usually fails
Unique user identification	45 CFR 164.312 access control, for systems holding ePHI	Map every cluster and cloud identity to a named person or service account. Confirm how Kubernetes authenticates users (certificates, OIDC tokens or a proxy) so logs show who acted.	Shared admin kubeconfig files or generic cloud roles make audit events unattributable.
Audit controls over activity	45 CFR 164.312 audit controls, for systems holding ePHI	Onboard Kubernetes audit logs, control plane logs and cloud provider activity logs. Write alert rules for privileged actions, secret reads and changes to RBAC.	Audit policy is left at a default that omits request bodies, secret access or service account activity.
Authentication and MFA for users	16 CFR 314.4 MFA for any individual accessing an information system	Log cloud console and cluster logins with the authentication method used. Alert on console or kubectl access that bypasses the SSO path.	Break-glass accounts and long-lived access keys sit outside the MFA flow and are not logged centrally.
Logging of authorized user activity	16 CFR 314.4 monitoring and logging of authorized user activity	Collect activity from authorized users across clusters, namespaces and cloud accounts into one index, with a common time source.	Each cluster ships logs to its own store, so activity across accounts cannot be correlated.
Kubernetes audit log coverage	Kubernetes authentication and API audit behavior, as documented by the Kubernetes project	Enable audit logging on the API server and forward it to the SIEM agent or collector. Confirm which audit levels capture the events your rules need.	Managed clusters restrict audit log configuration, so the SIEM sees only part of the control plane activity.
Runtime event capture	Falco documentation: custom rules, modern eBPF driver and plugin sources such as Kubernetes audit logs and CloudTrail	Deploy Falco on nodes and route its JSON output to a file or agent that Wazuh reads, as in the Wazuh and Falco integration. Tune rules to cut noise from short-lived pods.	Rules are copied from examples and never tuned, so alerts overwhelm analysts or are disabled.
Cloud control plane logs	Falco plugin documentation for AWS CloudTrail and Okta; cloud provider log documentation	Identify each account, subscription or project to onboard. Decide which events are ingested in full and which are filtered, and document the choice.	Logging is enabled in one region or account only, leaving gaps that no one notices until review.
Retention and tamper protection of logs	Logs must be kept and reviewed as evidence. Confirm retention periods with the framework your auditor applies	Keep cluster and cloud logs in write-once or separately controlled storage. Set index lifecycle rules that hold hot and archive tiers apart.	Short-lived pod logs are lost before they reach the SIEM, and archive copies are writable by the same admins they record.
Access control on the SIEM itself	45 CFR 164.312 unique user identification, applied to the logging platform	Restrict who can query, export or delete logs. Give cluster teams scoped dashboards and keep SIEM administrators separate from the systems they monitor.	Platform admins hold superuser rights on the SIEM and the clusters, so one account can change both.

How Kubernetes audit logs, runtime events and cloud logs reach the SIEM

Three source families reach a Wazuh SIEM from a Kubernetes and cloud estate, and each enters through a different path. The first is the Kubernetes API server audit log, which records requests made to the control plane. Kubernetes does not store normal users as API objects, so the audit trail only identifies people through whatever authenticator the cluster uses: X.509 client certificates, bearer tokens (including OpenID Connect and JWT), webhook token authentication or an authenticating proxy. Before go-live, confirm which method each administrator group uses, because that choice determines what identity appears in the log and whether a leaver's access can be traced to a named person. Audit policy and log file location are set on the API server itself, so the platform team must agree on the audit policy and the export path with the SIEM team before the cluster is handed over.

The second family is Falco runtime events. Falco is a cloud native runtime security tool that detects abnormal behavior on hosts, containers and Kubernetes nodes, and it alerts on what it sees. The Falco documentation describes detection and alerting, with actions taken by other components, and does not describe Falco blocking activity, so plan for prevention through admission controls, network policy or response tooling. Wazuh publishes a documented integration in which Falco on a K3s cluster, using the modern eBPF driver (the default), writes JSON events to a file that a Wazuh agent reads and forwards for rule matching. That integration is the example to study. Other distributions, kernel versions and Falco output configurations should be confirmed in a test cluster before anyone assumes the same path works.

The third family is cloud provider and plugin sources. Falco plugins add event sources beyond system calls, and the documented sources include Kubernetes audit logs, AWS CloudTrail and Okta. Cloud control-plane logs such as CloudTrail can also be collected directly by the Wazuh server or agents, depending on the design chosen. The decision to make is which path owns each source, so that one event is not ingested twice or lost in a gap between a plugin and a collector. Ask the implementation partner to document the source-to-collector map, the parser for each source and the field names used in detection rules, and to test one event from each family end to end before the SIEM is declared operational.

Which open source platforms fit a Kubernetes and cloud SIEM

A Kubernetes and cloud SIEM usually combines a host and log platform, a runtime detection source and an automation layer. The cards below separate the roles these tools play, the license terms that matter for procurement, and the checks to run before committing to one design.

Wazuh as the core SIEM

Wazuh covers the SIEM core: the indexer stores alerts, the server applies decoders and rules, the dashboard presents results and agents run on hosts and nodes. Its server can run as a cluster for horizontal scaling, and it manages agent configuration and upgrades remotely. It is distributed under GPL-2.0, and its 4.14 patch line is the current release line. Confirm how Kubernetes audit logs and cloud provider logs are parsed into its rules, and who maintains those decoders after upgrades.

Falco for runtime events

Falco is a cloud native runtime detection tool that watches hosts, containers, Kubernetes and cloud environments. It supports the modern eBPF driver by default and plugins for Kubernetes audit logs, AWS CloudTrail and Okta, so one rule set can cover node and control plane activity. It is Apache-2.0 licensed and became a CNCF Graduated project on February 29, 2024. Falco alerts but does not block activity, so confirm which response path you will build on top of it.

Falcosidekick for alert fan-out

Falcosidekick forwards Falco events to many destinations, so runtime alerts can reach the SIEM, chat channels and ticketing tools from one component. It is the practical bridge when Falco output must land in a file that a Wazuh agent reads or in an HTTP endpoint that a log pipeline ingests. Confirm which output paths your SIEM supports, how events are authenticated in transit, and how dropped or duplicated events are detected during node restarts.

Graylog or OpenSearch for log-heavy stacks

When Kubernetes and cloud log volume dominates and detection content is mostly search and dashboards, Graylog Open or an OpenSearch-based stack can carry the ingest load while host agents stay minimal. Check licensing before selection: OpenSearch is maintained under open source licenses, while Security Onion bundles the Elastic stack under the Elastic License 2.0. Confirm index lifecycle management, hot and cold tiers and the detection content you must write yourself, since these platforms carry less prebuilt content than Wazuh.

Security Onion for network context

Security Onion bundles Suricata, Zeek, osquery and the Elastic stack for threat hunting and monitoring. It adds network visibility between pods, nodes and cloud segments, which host-level logs cannot show alone. It is released under the Elastic License 2.0, which has usage terms your legal team should review. Confirm where sensors can sit in your cluster network, whether mirrored traffic is available in your cloud accounts, and how it sits next to Wazuh rather than replacing it.

Shuffle for response routing

Shuffle is a SOAR platform under AGPL-3.0 that takes alerts from the SIEM and runs enrichment and response steps, such as opening a ticket, isolating a workload or notifying an on-call engineer. In a Kubernetes setting, it turns a Falco or Wazuh alert into a documented action with an audit trail. AGPL-3.0 applies network-use obligations if you modify and host it for others, so confirm this with counsel. Confirm which cluster actions your playbooks may take and who approves them.

Where the SIEM sits relative to the clusters it monitors

Running the Wazuh server, indexer and dashboard on virtual machines or a dedicated Kubernetes cluster outside the workload clusters is the most common pattern. Wazuh documents all-in-one and step-by-step installs, a prebuilt OVA, Docker, Kubernetes, Ansible and Puppet paths, so the management tier can be built from any of them. Keeping it apart means a compromised workload cluster does not also control the place where its alerts are stored.

Blast radius: an attacker with cluster-admin rights can stop or tamper with agents and collectors, but cannot delete alerts already indexed in the management tier.
Log integrity: agents and forwarders send events outward, so the stored record survives a workload compromise. Confirm who holds write access to the indexer.
Network paths: only agent or forwarder traffic to the server ports and dashboard access from the SOC need to cross the boundary. Restrict each path to named sources.
Cluster API access: the management tier needs read access to Kubernetes audit log sinks, not admin credentials for the clusters.
Offline and sovereignty fit: the tier can be installed from offline media where the environment requires it.

Confirm with the platform team how audit log sinks reach the tier, which network policies apply, and who can administer the management nodes.

Managing alert volume from short-lived pods and autoscaled nodes

Short-lived pods and autoscaled nodes break three assumptions a traditional SIEM makes: that a host name identifies one machine for its lifetime, that an agent installed once keeps reporting, and that a rule firing on a workload means the same workload is still running. Replacement pods can reuse or generate host identities that look like duplicates in the Wazuh indexer, a new node may start before its Wazuh agent is deployed, and a terminated node can leave an agent shown as disconnected. Before you tune anything, confirm how your agent deployment handles node provisioning and how agent identities are named, because those choices determine whether alert history stays attributable.

Runtime noise is the larger problem. Falco, which is licensed under Apache-2.0 and ships a modern eBPF driver by default, can produce a steady stream of events from init containers, sidecars, cron jobs and node-level daemons. The reduction levers are rule design choices: scope rules to namespaces and labels so a rule for production payment pods does not fire on build agents, add cluster and workload metadata such as namespace, pod labels and node name to every event so an analyst can group alerts by workload instead of by pod, and suppress known-good system activity only after it is documented and reviewed. Falco alerts are routed to outputs such as files, syslog or HTTP(S) endpoints, and the Falco documentation describes detection and alerting, not blocking. Any suppression therefore hides an alert from analysts but does not stop the behavior, so record each exception with an owner and a review date.

The strongest volume reduction comes from correlating sources instead of alerting on each one. A Kubernetes audit event showing a new role binding, followed by a Falco event showing a shell started in the same namespace within a short window, is a far higher-confidence finding than either alone. Enrich audit events with the requesting identity, which Kubernetes authenticates through certificates, OpenID Connect tokens or an authenticating proxy, so that alerts name a person or service account. Ask your implementation partner to show, for a test cluster, which fields survive from audit log to Wazuh alert, and to demonstrate that a single pod restart produces one correlated record rather than a burst of unrelated ones.

How a cluster and cloud SIEM rollout runs in phases

The sequence moves from agreeing which clusters, cloud accounts and log sources are in scope to a SIEM that ingests them, alerts on them and hands over evidence the team can reproduce without the implementer present.

Scope clusters, accounts and log sources
The implementer and your platform, security and compliance leads list every cluster, cloud account, region and log source in scope, then record which Kubernetes distribution, control plane topology and identity provider each cluster uses. Owners are named for each source and for the audit logs that must be retained. The step closes with a signed scope document that states what is monitored, what is excluded and why, and who approves changes to it.
Build the Wazuh stack in the chosen deployment
The team installs the Wazuh indexer, server and dashboard in the deployment model agreed in scope, whether that is a package installation, a container or Kubernetes deployment, or an offline install where the network requires it. The server is sized for the expected agent count and configured as a cluster if horizontal scaling is needed. The step is done when the dashboard shows test agents reporting, the indexer is healthy and backups of the indexer and configuration are running.
Enable Kubernetes audit logging and Falco
Engineers turn on API server audit logging with a policy that records authentication, authorization and changes to secrets and RBAC objects at a level the security team approved, and they route those logs to a node or collector that a Wazuh agent can read. Falco is deployed with the modern eBPF driver by default, and its JSON output is written to a file that a Wazuh agent forwards. The step is complete when a controlled test action, such as a privileged pod creation, produces a Kubernetes audit event and a Falco alert that both appear in the dashboard.
Onboard cloud provider and identity logs
The team connects cloud control plane logs, such as audit trails from each provider, and identity provider sign-in and administrative events into the SIEM through the collection method each provider supports. Credentials for log readers are scoped to read-only access and stored in the secrets platform, not in configuration files. The step closes when a sample administrative action in each account is visible with the actor, source address and time, and the team has confirmed the timestamps line up across sources.
Tune rules for ephemeral workloads
Pods and jobs that live for minutes create alerts that name workloads no one will ever investigate, so engineers review the first weeks of alert volume with the platform owners. They suppress known-good patterns such as scheduled jobs and node maintenance, add rules that key on workload labels, namespaces and service accounts rather than pod names, and confirm that deleted workloads still leave a traceable record. The step is done when the alert queue is sized for the analyst team and each retained rule has a named owner and a test that proves it fires.
Validate evidence and hand over
Engineers and the compliance lead run the scoped test scenarios again, export the audit log samples, alert records and configuration history that an assessor would request, and confirm that retention and access controls on the SIEM itself match the approved design. The implementer then documents the runbooks for upgrades, rule changes and adding a cluster, and walks the internal team through them. The handover is complete when the internal team has reproduced one full detection and evidence export without the implementer present.

Evidence auditors ask for and the component that produces it

This table maps each piece of evidence an assessor typically requests for a Kubernetes and cloud SIEM to the component that produces it and the records the team must still write down. Read it as a checklist: the platform generates the raw evidence, but the policy, review and disposition records come from your own process.

Evidence	Producing component	What the team must still document
Audit trail of Kubernetes API access	Kubernetes audit policy on the API server, shipped to the SIEM through an agent or log forwarder	The audit policy scope and level, who approved it, where audit files are stored, and which API requests are deliberately excluded
Runtime alerts and their dispositions	Falco rules and alerts, forwarded through a file read by the Wazuh agent or through Falcosidekick	Rule ownership, tuning history, which alerts were triaged, who closed them and the reason, and escalation records
Cloud control plane change logs	Cloud provider audit logs (for example, AWS CloudTrail), pulled into the SIEM by the platform's log collection	Which accounts and regions are covered, retention configured at the provider, and who reviews the trail and how often
Retention settings and integrity controls	Wazuh indexer index lifecycle settings, storage configuration and access controls on the indexer	Retention periods mapped to each framework, hot and archive tiers, and how log immutability is proven to the assessor
Dashboard compliance views for HIPAA and PCI DSS	Wazuh dashboard prebuilt compliance views, which report on rule coverage from alerts and agent data	Confirmation that each rule and view maps to the control claimed, plus the periodic review record that shows the view was used
Access logs for the SIEM itself	Wazuh dashboard and API authentication logs, and audit records from the identity provider used for SIEM login	Named user accounts, role assignments, privileged access approvals and the review of who viewed or changed SIEM data

What teams ask before running a cloud-native SIEM

What does a self-hosted Kubernetes SIEM cost to run?

Most of the cost comes from three recurring drivers: the compute and storage that grow with daily ingest and retention, the engineering time needed to write and tune detection rules, and any paid support or enterprise editions you choose. The open-source software itself carries no license fee for the core components, but Wazuh's core is GPL-2.0 and some vendors gate features behind enterprise licenses, so confirm which features you need are in the free edition. Ask any implementation partner to quote separately for the initial build, the recurring platform operation and the detection content, and to state the ingest and retention assumptions behind the storage estimate. Kubernetes audit logs and runtime events from short-lived pods can raise ingest faster than teams expect, so model that volume before you commit to a retention period.

How long does a cloud-native SIEM implementation take?

The timeline depends on how many clusters and cloud accounts you onboard, whether the platform runs in your cloud or on-premises, how many log sources need parsing, and how much detection content you build. A first phase usually covers the SIEM core, one cluster and the highest-value cloud audit trails, and later phases add clusters and sources. The schedule should be fixed in writing as part of a scoped engagement, with each phase's deliverables named. Ask for the assumptions behind the schedule, including which environments the team needs access to and when change approvals are required. We do not state a fixed duration here because it changes with the scope.

What does the platform team need to provide for a SIEM project?

The platform team needs to provide access to the clusters and cloud accounts, a place to run the SIEM (virtual machines, containers or a Kubernetes cluster that is separate from the workloads it monitors), network paths from the clusters to the collectors, and an owner who can approve changes to audit policies. Engineers also need to decide where agents run, how Kubernetes audit policy is configured on the control plane, and how secrets for collectors are stored. Expect the platform team to review each log source before onboarding it. Confirm these responsibilities in the statement of work so the platform team knows its time commitment before the project starts.

Can our own team run a Kubernetes SIEM without a partner?

Yes, many teams do, provided they have engineers who understand Linux, Kubernetes, cloud audit services and detection logic, and they accept ongoing operational work. The Wazuh components (the indexer, server, dashboard and agents) are documented for several deployment paths, including Kubernetes, so a capable team can install and run them. The harder parts are sustained: keeping the platform upgraded, tuning rules to reduce noise from short-lived workloads, and producing evidence for auditors. A useful test is whether you can name the person who reviews alerts each week and who owns upgrades. A partner can implement the initial build and hand over documentation, or support you through a retainer after go-live.

Does Falco replace a SIEM for Kubernetes monitoring?

No. Falco detects abnormal runtime behavior on hosts, containers and Kubernetes, and sends alerts to outputs such as standard output, a file, syslog or an HTTP endpoint. Its documentation describes detection and alerting, with actions taken by other components, and does not describe Falco blocking activity. A SIEM collects events from many sources, including Falco, Kubernetes audit logs and cloud provider logs, then correlates them, stores them with retention and supports investigation and reporting. Wazuh publishes an integration where Falco writes JSON events to a file that a Wazuh agent reads, so Wazuh rules can alert on them. Treat Falco as one event source feeding the SIEM, not as the SIEM itself.

How do Kubernetes upgrades change audit log formats?

Upgrades can change the fields, API versions or event structure your parsers expect, so a parser that worked on one minor release may silently drop or misread events after the next. Kubernetes maintains only the three most recent minor releases, so plan a recurring upgrade cycle and treat every upgrade as a change to the logging pipeline. Practical controls include versioning your decoders and rules, running them against sample audit logs from each target version in a test cluster before production, and alerting when a source stops producing events. Kubernetes also requires the API server to be upgraded one minor version at a time, which gives you a predictable sequence to test against. Confirm the log formats for your exact version with the Kubernetes release notes before you schedule the change.

Do cloud and Kubernetes logs stay inside our infrastructure?

They can, because a self-hosted SIEM runs in the environment you choose, whether that is your cloud accounts, a data center or an air-gapped network. Logs from Kubernetes audit, Falco and cloud provider trails are then stored and processed only where you deploy the platform. Two details need checking. First, the collectors and any cloud-side export services must send data only to your SIEM endpoint, not to a third-party service. Second, backups, snapshots and vendor support access must follow the same boundary, and the SIEM's own logs can contain personal data that needs the same protection. Document where each component runs and how data leaves the cluster, so auditors can trace the path.

Questions to ask an implementation partner about Kubernetes and cloud coverage

Start with how the partner gets Kubernetes audit logs into the SIEM, because the answer differs sharply between managed and self-managed clusters. On a self-managed control plane, ask who owns the audit policy file, where the kube-apiserver writes its audit output, and which agent or forwarder ships it to the Wazuh server. On a managed service, ask which audit log categories the cloud provider exposes, how they are exported, and whether the partner can show a test event from each cluster arriving in the Wazuh indexer. Ask for the decoder and rule set they will use for Kubernetes audit events, and whether it is written for your cluster versions or copied from a generic template. Also ask how authentication events are mapped, since Kubernetes users authenticate through client certificates, OIDC tokens or an authenticating proxy rather than user objects, so the SIEM must correlate several identity sources.

Next, ask how Falco rules are tested before they reach production. Request the test plan for a K3s cluster using the modern eBPF driver, and for any other distribution you run, including the kernel versions and node images covered. Ask whether Falco events are written to a file that a Wazuh agent reads, as in the documented K3s integration, or forwarded by another route, and who tests that path after a node image change. Ask how rule changes are versioned, reviewed and rolled back, and whether the partner can replay recorded events against a rule before it is enabled. Confirm that Falco is treated as a detection source only, since its documentation describes alerting and not blocking, so any response step must be agreed separately.

Finally, ask about upkeep and alert volume. Ask how the partner plans Wazuh upgrades alongside the Kubernetes version skew policy, which requires the kube-apiserver to be upgraded first and allows kubelets to lag by up to three minor versions, and how they confirm that decoders still parse events after each change. Ask how short-lived pods and autoscaling events are filtered or aggregated so that alert volume stays reviewable, and who approves those thresholds. Ask who writes and tunes the detection content, and whether your own engineers keep rule ownership after handover. Finally, ask what support covers after go-live: response times, which Kubernetes releases and Wazuh 4.14 patch releases are covered, and whether upgrades and continuous rule maintenance are included or sold as a retainer. Get each answer in the written scope.

How DeployOpen scopes and builds a cluster-aware SIEM

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a SIEM that watches Kubernetes and cloud workloads, we start with the clusters, log sources and retention rules you actually run, then build the collection path and detections in writing before anything goes live.

How we scope

Inventory every cluster, control plane, namespace group and cloud account whose audit, runtime and control-plane logs the SIEM must receive.
Agree in writing which Kubernetes audit policy, Falco rule set and cloud provider log sources are in scope, and which are excluded.
Record the daily ingest estimate, hot and archive retention, and where the SIEM sits relative to each cluster and its network segment.

How we build

Deploy the Wazuh indexer, server and dashboard, then connect Falco output to Wazuh agents on the nodes where Falco runs.
Configure decoders and rules for Kubernetes audit events and cloud trail sources, then tune alert thresholds for short-lived pods and jobs.
Test each log path end to end with controlled events, confirming that alerts reach the intended triage queue and that no source silently drops.

How we hand over

Deliver architecture diagrams, data flow maps, source inventories and detection rule documentation tied to the agreed scope.
Document upgrade steps for Wazuh, Falco and Kubernetes version changes, including how the SIEM adjusts when cluster versions move.
Run a handover session with your platform and security teams covering alert triage, rule changes and how to verify log integrity.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, covering new clusters and log sources as they are added.
Confirm during scoping what support hours, response expectations and upgrade cadence the retainer includes, since these depend on the written agreement.