Windows Host Agent

Installing a Wazuh Agent on the Windows Host

Install a Wazuh agent on the Windows host, connect it to the Kubernetes-hosted Wazuh lab through port-forwarding, and verify the Windows endpoint in Wazuh.

Kubernetes SOC Field Lab · Practical Security Operations

Domain alignment

Endpoint Monitoring SIEM Operations Incident Response

Successful checkpoint

Before moving into event testing, confirm the Windows host endpoint is visible and active in Wazuh.

Expected dashboard evidence:
- Endpoint status: active
- Endpoint name: windows-host-lab or the Windows hostname
- Endpoint ID: visible in Wazuh
- IP address: 127.0.0.1 in this port-forward lab
- Operating system: Microsoft Windows
- Last keep alive: recent
- System inventory: populated
- Events: present
- MITRE ATT&CK, SCA, vulnerability, or inventory panels: loading data

Lab milestone: At this point, the SOC lab has two monitored surfaces: the Kubernetes node agent from the DaemonSet and the Windows host agent from the dashboard deployment workflow.

What this lesson covered

Why Windows cannot use Kubernetes internal DNS names
Why kind on Windows may not expose NodePorts directly to the Windows host
How to use kubectl port-forward for Wazuh agent enrollment and event traffic
How to use the Wazuh dashboard Deploy new agent workflow
How to set the Windows server address to 127.0.0.1 for this port-forward lab
How to verify the Windows endpoint in Wazuh

Keep these port-forwards running for the next lab

The next lesson generates safe Windows events. Keep these two PowerShell windows open while testing Windows telemetry:

kubectl -n wazuh port-forward --address 127.0.0.1 service/wazuh 1515:1515

kubectl -n wazuh port-forward --address 127.0.0.1 service/wazuh-workers 1514:1514

Document endpoint coverage

Windows agent name:
Windows endpoint ID:
Windows OS version:
Manager address used:
Port-forward required:
Registration port:
Event port:
Agent status:
Last keep alive:
Inventory populated:
Known limitations:
Next test event:

Answer key

The Windows host is outside Kubernetes, so it cannot resolve internal service names like wazuh.wazuh.svc.cluster.local.
The lab uses 127.0.0.1 because port-forwarding maps Windows localhost into the Wazuh services running in Kubernetes.
The endpoint is ready for the next lesson when it is active, has a recent keep alive, and shows inventory or event data.