The landscape of modern infrastructure has undergone a massive paradigm shift from monolithic, long-lived virtual machines to ephemeral, highly dynamic, and orchestrated containerized workloads. In this ecosystem, Kubernetes serves as the primary engine for container orchestration, managing the lifecycle of microservices packaged with their specific dependencies and configurations. While Kubernetes provides unparalleled automation for deployment, scaling, and self-healing, this very dynamism introduces significant security observability challenges. Traditional security monitoring tools often rely on stable hostnames and persistent IP addresses to track endpoint behavior. However, in a Kubernetes environment, pods are frequently rescheduled, restarted, or scaled, leading to transient IP addresses and changing pod identities. This volatility can result in "blind spots" where security events are lost, or where a single logical endpoint appears to multiple different identities in a Security Information and Event Management (SIEM) system, fragmenting the audit trail and complicating incident response.
To combat this, Wazuh—a comprehensive open-source security monitoring platform providing SIEM and XDR capabilities—offers specialized deployment strategies designed specifically for the nuances of Kubernetes. Integrating the Wazuh agent into a cluster requires a departure from standard installation methods to ensure that security telemetry remains continuous, even when the underlying containers are destroyed and recreated. The fundamental goal is to maintain a persistent identity for the Wazuh agent, ensuring that the Wazuh manager can map new container instances back to their previous historical records, thereby preserving the integrity of the security event timeline and ensuring continuous visibility across the entire cluster.
Architectural Paradigms for Agent Deployment in Containerized Environments
When integrating the Wazuh agent into a Kubernetes cluster, the primary architectural decision revolves around how the agent is coupled with the application container it is intended to monitor. This decision impacts the deployment's resilience, the complexity of the manifest files, and the resource overhead required for security telemetry.
The following table outlines the primary deployment strategies discussed for Kubernetes environments:
| Deployment Strategy | Mechanism | Primary Benefit | Implementation Requirement |
|---|---|---|---|
| Sidecar Deployment | Agent runs in a separate container within the same Pod as the application. | Isolation of application logic from security agent logic. | Pod-level resource management and shared volumes. |
| Included Deployment | Agent is baked into the application container or deployed via specific templates. | Simplified lifecycle management for specific workloads. | Kubernetes StatefulSets and Persistent Volumes. |
The Sidecar deployment model leverages the concept of a Pod as the basic operational unit in Kubernetes. By placing a Wazuh agent container within the same Pod as the application container, the two share the same network namespace (allowing communication via localhost) and can share storage volumes. The Included deployment model, conversely, often relies on Kubernetes StatefulSets to ensure that even as pods are recreated, they retain specific characteristics that allow the Wazuh manager to recognize them.
Core Components of a Wazuh Deployment on Kubernetes
A functional Wazuh deployment on Kubernetes is not a single entity but a distributed stack of microservices, each fulfilling a specific role in the telemetry pipeline. When deploying the full stack, one typically manages a cluster of components including the Wazuh Indexer, the Wazuh Manager, and the Wazuh Dashboard.
- Wazuh Indexer: The component responsible for storing and indexing the security events and logs. It functions as the searchable data backend.
- Wazuh Manager: The central brain of the system that analyzes data, performs rule matching, and manages agent communication.
- Wazuh Dashboard: The web-based user interface used for visualizing alerts, managing agents, and performing security investigations.
- Filebeat: Often used within the stack to ship logs from the indexer or manager to the indexing component.
The deployment process involves cloning the official Wazuh Kubernetes repository to access the necessary manifests. The repository structure is vital for the automated deployment of these services.
bash
$ git clone https://github.com/wazuh/wazuh-kubernetes.git -b v4.14.5 --depth=1
$ cd wazuh-kubernetes
The use of --depth=1 is a best practice in CI/CD and automated deployment environments to minimize the download size by only fetching the latest commit of the specified branch (in this case, v4.14.5).
Cryptographic Identity and Certificate Management
Security in a distributed Kubernetes environment relies heavily on Mutual TLS (mTLS) to ensure that all communication between the Wazuh components is encrypted and authenticated. Manually managing certificates for a dynamic cluster is prone to error; therefore, the deployment utilizes automated scripts to generate the necessary TLS certificates.
The certificate generation process involves creating a Root Certificate Authority (CA) and then issuing specific certificates for the Indexer, the Dashboard, and the Filebeat component. This ensures that each service in the stack can verify the identity of the others.
For the Wazuh indexer cluster, the following script is utilized to automate the generation of self-signed certificates:
```bash
wazuh/certs/indexercluster/generatecerts.sh
```
When executing this process, the system generates several key files:
- Admin certificates: Used for administrative access to the indexer.
- Node certificates: Used for inter-node communication within the indexer cluster.
- Dashboard certificates: Used to secure the web interface communication.
- Filebeat certificates: Used for secure log shipping.
If a user wishes to use their own existing Public Key Infrastructure (PKI) rather than the self-signed certificates provided, they must replace the generated files with their own valid certificates. This is a critical requirement for production environments where a centralized corporate CA is mandatory for compliance.
Furthermore, for specific integrations like the Kubernetes Webhook, a manual certificate creation process may be required. This involves creating a directory for the certificates and generating a configuration file (csr.conf) that specifies the Subject Alternative Name (SAN) to include the Wazuh server IP.
The manual generation of the Root CA involves the following command structure:
```bash
openssl req -x509 -new -nodes -newkey rsa:2048 -keyout /var/ossec/integrations/kubernetes-webhook/rootCA.key -out /var/ossec/integrations/kubernetes-webhook/rootCA.pem -batch -subj "/C=US/ST=California/L=San Jose/O=Wazuh"
```
Agent Enrollment and Manager Connectivity
Once the Wazuh stack is operational on the Kubernetes cluster, the next phase is the enrollment of agents. In a Kubernetes context, agents need to know how to reach the manager, especially when the manager is behind a LoadBalancer or a NodePort.
To begin enrollment, one must identify the external endpoints of the Wazuh services. The wazuh service, which provides the registration and communication capabilities, is typically exposed via a LoadBalancer.
To find the necessary connection information, the following command is used:
```bash
kubectl get services -n wazuh
```
The output of this command provides the EXTERNAL-IP for the various services. For agent enrollment, the WAZUH_MANAGER variable must be set to the External IP of the wazuh-workers load balancer, and the WAZUH_REGISTRATION_SERVER must be set to the External IP of the wazuh load balancer.
The following table summarizes the typical service structure found in a standard Wazuh Kubernetes deployment:
| Service Name | Type | Port(s) | Purpose |
|---|---|---|---|
| indexer | ClusterIP | 9200 | Data Indexing |
| dashboard | ClusterIP | 5601 | User Interface |
| wazuh | LoadBalancer | 1515, 55000 | Agent Management/Registration |
| wazuh-workers | LoadBalancer | 1514, 1515 | Agent Communication |
| Wazuh-indexer | ClusterIP | 9300 | Indexer Inter-node communication |
The enrollment process requires a registration password. By default, the password used for enrolling new agents in a Kubernetes deployment is password. However, for security purposes, this can be retrieved from the manager pod using the following command:
```bash
kubectl exec -it wazuh-manager-master-0 -n wazuh -- cat /var/ossec/etc/authd.pass
```
Resilience Testing: Verifying Identity Persistence
The ultimate metric of success for a Kubernetes deployment strategy is its ability to maintain agent identity despite the ephemeral nature of pods. To validate that the deployment strategy (specifically the "Included" strategy using StatefulSets) is functioning correctly, a manual disruption test should be performed.
To test the resilience of the deployment, a user should delete a specific agent pod and observe how the system handles the recreation.
Identify the target pod:
bash $ kubectl -n juice-shop-wazuh-included get podsDelete the pod to trigger a Kubernetes restart/reschedule:
bash $ kubectl delete pod -n juice-shop-wazuh-included juice-shop-wazuh-agent-0Monitor the status of the pod as it enters the
ContainerCreatingand subsequently theRunningstate:
bash $ kubectl -n juice-shop-wazuh-included get pods -w
The expected outcome of this test is two-fold. First, the Wazuh manager must recognize the new pod instance (which will have a different IP address) as the same agent that was previously known as juice-shop-wazuh-agent-0. Second, when checking the Wazuh dashboard, the agent's historical data should be continuous, showing no gap in telemetry despite the pod being deleted and recreated. This confirms that the combination of Kubernetes StatefulSets and Persistent Volumes is successfully preserving the agent's unique identity and registration keys.
Troubleshooting and Operational Maintenance
Maintaining a Wazuh deployment on Kubernetes requires ongoing attention to the health of the various microservices. Because the stack is distributed, troubleshooting often requires looking at logs across multiple layers: the container logs, the Kubernetes events, and the Wazuh manager's internal logs.
When performing upgrades, it is vital to follow the official procedure for upgrading Wazuh on Kubernetes, which involves updating the image tags in the manifests and ensuring that the underlying data volumes (managed by Persistent Volume Claims) remain intact. A failed upgrade can result in data corruption in the indexer, making the backup of the indexer data a critical prerequisite for any maintenance operation.
Cleaning up a deployment is equally important to avoid resource leakage and unnecessary cloud costs. To remove the deployment, one must not only delete the pods but also ensure that the Persistent Volumes and LoadBalancer services are decommissioned.
Analysis of Security Observability in Dynamic Environments
The integration of Wazuh into a Kubernetes environment represents a critical convergence of security operations and cloud-native orchestration. The ability to maintain a persistent identity for agents in a landscape of ephemeral workloads solves one of the most significant hurdles in modern security monitoring: the "identity fragmentation" problem.
By utilizing Sidecar or Included deployment patterns, organizations can transition from reactive, host-centric security models to proactive, workload-centric models. The resilience demonstrated through the use of StatefulSets ensures that security telemetry is not just a stream of disconnected events, but a coherent, longitudinal record of behavior. This continuity is essential for detecting sophisticated, low-and-slow attacks that might otherwise be lost in the noise of container churn. Ultimately, the success of such a deployment hinges on rigorous certificate management, precise configuration of LoadBalancers for agent connectivity, and the continuous verification of identity persistence through scheduled resilience testing.