Learn Wazuh - Docker and Kubernetes Integration

#Introduction

In episode 12, we connected Wazuh to AWS, Azure, and GCP. Now it's time to go down to the layer closer to applications: containers. Containers and Kubernetes have become the backbone of modern deployment, but they also open up new attack surfaces.

Wazuh has two approaches for container environments. For standalone Docker, there's wazuh-docker, which runs as an agentless listener near the Docker daemon. For Kubernetes, we can deploy the entire Wazuh stack inside the cluster, or monitor the cluster as an ordinary node.

In episode 13, we'll discuss both approaches. We start with Docker, then move into Kubernetes: deploying Wazuh with a helm chart, monitoring pods and namespaces, up to audit logs and CIS benchmarks.

#Understanding the Docker Listener

Containers are ephemeral. An image can contain software completely different from the host. That's why Wazuh uses a special module called wazuh-docker.

This module is essentially a container running a listener. It reads the Docker socket and records all daemon events, such as container start, stop, pause, kill, and restart. It also captures image events, for example when a new image is pulled.

Because the listener must see the Docker socket, it needs to be run with access to that socket. In a simple deployment, just mount the socket and the container log directory into the listener.

docker run -d \
  --name wazuh-docker \
  --restart always \
  -e API_PROTOCOL=https \
  -e API_HOST=manager.example.com \
  -e API_PORT=55000 \
  -e API_USERNAME=wazuh-wui \
  -e API_PASSWORD=SecretWUI \
  -v /var/lib/docker/containers:/var/lib/docker/containers \
  -v /var/run/docker.sock:/var/run/docker.sock \
  wazuh/wazuh-docker:latest

The environment variables above tell the listener the manager address and API credentials for sending events. Once running, the listener starts collecting events and forwarding them to the manager.

#Monitored Container Events

Events coming in from the listener are categorized into several groups. Wazuh already provides built-in rules for these groups, named docker.

• Container events: create, start, stop, kill, pause, restart, and destroy.
• Image events: pull, push, and tag.
• Network events: connect and disconnect on the Docker network.
• Daemon events: changes to the daemon's own status.

Every event matching a rule produces an alert. For example, a container restarting too often in a short period can be a signal of a crash-looping container or a denial of service attack.

Example container alert in JSON format

{
  "agent": {"name": "docker-host"},
  "rule": {"description": "Docker: container stopped"},
  "data": {"docker": {"status": "stop", "id": "abc123"}},
  "level": 5
}

#Monitoring Container Logs

Besides daemon events, we also need the log content from inside containers. Docker stores each container's logs in /var/lib/docker/containers. The listener we installed reads that directory, so container stdout and stderr logs also flow into the manager.

That way, a single data flow covers two things at once: container lifecycle events and the logs produced by applications inside them. Searching for application errors, failed login attempts, or attack patterns inside containers can be done directly from the Wazuh dashboard.

To inspect container logs from the Docker CLI side, use the following command.

docker logs --tail 50 nama-container

#Kubernetes Integration

For Kubernetes clusters, Wazuh can be deployed directly into the cluster. This approach puts the entire SIEM stack in the same environment as the workloads being observed.

#Deployment with a Helm Chart

The easiest way is using the official helm chart. First, clone the wazuh-kubernetes repository, then install the chart with a dedicated namespace.

git clone https://github.com/wazuh/wazuh-kubernetes.git

cd wazuh-kubernetes
helm install wazuh . -f values.yaml \
  --namespace wazuh --create-namespace

This chart deploys the full set of components: manager, indexer, and dashboard. On small clusters, all components can run in the same namespace. On large clusters, you can separate them as needed, for example the indexer in a dedicated node group.

#Monitoring Pods, Namespaces, and Events

The Wazuh agent can be installed as a DaemonSet so every node is monitored. This combination provides several capabilities:

• Capturing logs from all pods in all namespaces.
• Detecting crash-looping pods via container events.
• Seeing suspicious image or label changes.
• Monitoring each node's resource utilization as alert context.

For deeper Kubernetes visibility, enable audit logging in kube-apiserver. The audit log contains every API request to the cluster, who made it, and from where. Wazuh reads this audit log as a normal log file via the localfile configuration on the agent.

kubectl logs -n kube-system kube-apiserver --tail 100

Detection rules for Kubernetes are already provided in the kubernetes group. Alerts like role binding changes, privileged pod creation, or suspicious secret access form directly without needing extra rules.

#CIS Benchmark for Kubernetes

Wazuh also ships an SCA policy for Kubernetes, which we know from the SCA discussion in a previous episode. This policy checks the control-plane, node, and other component configuration against the CIS Kubernetes Benchmark standard.

Scan results appear as a cluster of findings and per-item recommendations. For example, the policy will flag etcd running without encryption, a kubelet with insecure ports, or control-plane certificates that don't expire on time.

sudo wazuh-control restart
sudo cat /var/ossec/etc/shared/kubernetes.yml

#Comparing Docker and Kubernetes

Here's a summary of the differences between the two environments' approaches.

• Standalone Docker: one wazuh-docker listener on the host is enough, no full stack deployment.
• Large Docker: install the agent on the host and add a listener for wider coverage.
• Kubernetes: deploy the Wazuh stack with a helm chart, or install an agent DaemonSet.
• Advanced Kubernetes: add the kube-apiserver audit log for API visibility.
• Both: use the SCA policy against the benchmark for automatic hardening.

#Conclusion

In episode 13, we covered Wazuh integration with Docker and Kubernetes. For Docker, the wazuh-docker listener captures container events and application logs without changing workloads. For Kubernetes, we deploy the Wazuh stack with a helm chart, monitor pods and namespaces via an agent DaemonSet, and deepen visibility with kube-apiserver audit logs and the CIS benchmark.

Key takeaways:

• wazuh-docker is an agentless listener that reads events from the Docker socket.
• API environment variables are used to route events to the manager.
• Container logs enter through the /var/lib/docker/containers directory.
• The official helm chart deploys manager, indexer, and dashboard inside the cluster.
• The kube-apiserver audit log gives visibility over every API request.
• The kubernetes SCA policy provides hardening according to the CIS Benchmark.

With containers and Kubernetes monitored, we move up a level to architecture. In episode 14, we'll discuss the distributed Wazuh architecture: a multi-node indexer cluster, a three-node manager cluster, load balancing, and high availability for production scale. See you there!