Wazuh container security for Docker and Kubernetes

Container activity reaches Wazuh through the same pipeline as every other endpoint signal, and the host agent is where that pipeline starts. Wazuh has four components. Agents installed on endpoints collect data and send it to the Wazuh server, which analyzes that data with decoders that parse each event into fields and rules that decide which events become alerts. The Wazuh indexer is a full-text search and analytics engine that stores those alerts, and the Wazuh dashboard is the web interface where analysts search and review them. For Docker, container events enter at the agent stage, on the Linux host that runs the Docker engine. The server and indexer have no direct view of containers, so everything they learn about container activity arrives through the agent.

The most important design fact is that the agent runs on the host, not inside each container. What Wazuh can say about containers therefore depends on what the host and its container runtime expose to the agent. The Docker listener is the component that receives runtime events on the host, and the event types it emits, the fields attached to each event and the settings that switch it on are all version-specific. Before you plan detections, confirm the exact listener configuration, the event fields and the Docker versions supported for your Wazuh release in the current Wazuh documentation. Treat those details as checked inputs to your design, and do not rely on older guides or community posts to fill the gaps.

A host-side view has predictable gaps, and your design should name them early. Short-lived containers may start and stop between the moments your configuration captures, so confirm how events are queued and delivered when an agent restarts or loses its connection to the server. Activity inside a container's own process space is not automatically visible as container events, so decide whether host-level telemetry, such as process or file monitoring, is also needed for the workloads you care about. Container names, labels and image tags are only useful for filtering if they appear in the event fields your release actually emits, which is another reason to verify fields on a test host before writing any rules.

On the server, decoders and rules determine whether a container event becomes an alert that someone sees. Default rules are written for general runtime activity and may not match your image naming, label scheme or the behaviors that matter to your risk model. Review the shipped rule set against a short list of container behaviors your organization treats as significant, for example (illustrative) starting a privileged container or mounting host paths into a container, and confirm in the current documentation which rules exist for your release. Keep custom decoders and rules in version control, because you will need to reapply and retest them during Wazuh upgrades. The indexer stores the resulting alerts, so the retention and access settings you choose there will govern how long container alerts stay searchable.

Start with a short verification run before committing to a container monitoring design. Use a non-production Linux host with the Wazuh agent installed and the Docker engine running at a version the current Wazuh documentation lists as supported. Start, stop and run commands in test containers, then trace each event from the agent to the server decoder, the matched rule and the indexed alert in the dashboard. Record which fields arrive, which events are missing and how an agent restart affects delivery. These results show what your host hardening and Kubernetes work can rely on, and they show where a dedicated runtime security tool will still be needed.

Wazuh vulnerability detection on a container host correlates the software inventory that the Wazuh agent collects from the host with vulnerability data from either the Wazuh Cyber Threat Intelligence (CTI) platform or an offline vulnerability repository. The agent reports the packages the host operating system has installed, including the container runtime and orchestration packages on each Docker or Kubernetes node. Those packages can be matched to advisories, but only if the inventory is complete and current. Before you rely on the results, confirm that an agent runs on every node, that each node appears in the dashboard with a populated package list, and that the inventory refreshes after patching.

A host inventory describes what is installed on the host, so it does not describe what runs inside your containers. Packages baked into container image layers, including base image libraries and application dependencies, need separate confirmation through image scanning in your registry or build pipeline. The same applies to packages inside running containers that were added after the image was built. Ask the team who owns image scanning, which images it covers, and whether it runs on every build and on images already stored in the registry. Record any image layer or in-container package that no scanner reviews as a named gap in your risk register.

The inventory is only one input. The feed decides which advisories can match a package at all. If your deployment uses the Wazuh CTI platform, confirm which data it draws on and how often your server receives updates. Networks without internet access can use an offline vulnerability repository instead, as described in the Wazuh offline installation guide. That repository must be built, transferred and imported by your team, so its content is only as current as your last transfer. Ask who performs each transfer, how often it happens, and how you will show the date of the data used in each assessment.

Treat the output as a scoped list, not a complete picture of container risk. Run three checks before you report results: compare the number of agent-reporting nodes with your cluster node list, select one image in production and confirm which tool scans its layers, and check that one known package version on a node appears with the expected finding. Where any check fails, fix the inventory or feed first, then document what remains uncovered. Your team will also need a runtime control for container behavior, which Wazuh vulnerability detection does not provide on its own.

Wazuh is a strong fit for collecting host and container signals, correlating them and alerting on them, but some questions about container behavior sit outside what host agents and log collection can answer on their own. Two are worth settling before you finalize the design: how much process and network activity inside individual containers you need to see at a finer grain than the host and audit logs expose, and whether you need to block a workload at deploy time rather than detect it afterward. Those two needs usually point toward a dedicated runtime security tool or an admission control layer, and they should be decided explicitly rather than assumed to be covered.

Deploy-time control is the clearest example. Kubernetes admission control is where a policy can refuse a pod that runs as root, mounts a host path or skips a required image signature. Wazuh can report on the Kubernetes audit log and flag a suspicious workload after it is created, but it does not sit in the admission path to stop the request. If your policy requires prevention, plan an admission policy engine or the built-in Pod Security Standards enforcement as a separate control. Review the Pod Security Standards levels your namespaces need and decide which team owns the policy definitions, the exceptions process and the change history.

Where a runtime tool is in the picture, the division of labor should be written down before the first deployment. A typical split is that the runtime tool owns fine-grained process, file and network policy inside containers and raises its own alerts, while Wazuh receives those alerts, correlates them with host logs, audit records and vulnerability findings, and drives case workflow. The integration is usually a forwarder or webhook that delivers alerts into the Wazuh indexer or a log path that Wazuh decodes. Confirm with each product's vendor which alert formats, fields and enforcement actions it supports, and whether either side can take an action on the other.

Treat the integration as untested until you have proven it. Build a test plan that triggers known events in a non-production cluster, such as a privileged pod, an unexpected outbound connection and a modified container file, then checks that each event appears in both systems with the fields your rules and dashboards expect. Verify that alert volume is manageable, that duplicate alerts are suppressed, and that the runtime tool keeps working when Wazuh is upgraded or restarted. Ask both vendors for their documented upgrade compatibility and support matrix before you rely on the link for production monitoring.