Topic starter
19/08/2026 4:07 pm
TL;DR: Kubernetes deployments can break monitoring continuity when pod identity changes, so Wazuh recommends sidecar and included patterns that preserve agent registration, hostname, and log continuity across reschedules, according to Wazuh. The core issue is not container orchestration itself but whether persistent workload identity survives the lifecycle of an ephemeral pod.
Editorial analysis by NHI Mgmt Group, based on content published by Wazuh: “Wazuh agent deployment strategies for persistence in Kubernetes”.
Key questions
Q: How should teams preserve monitoring continuity when Kubernetes pods are recreated?
A: Use persistent storage for the agent’s registration and configuration, and run it in a StatefulSet so rescheduling does not create a new monitoring identity.
Q: When does bundling a security agent into the application image create more risk than it reduces?
A: Bundling creates more risk when the organisation needs clear separation between the monitored workload and the monitoring component.
Q: What breaks when an NHI agent loses its persisted state in Kubernetes?
A: The manager may treat the recreated pod as a new identity, which disrupts event lineage, history, and continuity of visibility.
Practitioner guidance
- Design for persistent agent state Store Wazuh agent registration data, configuration, and hostname persistence on a volume that survives pod recreation so the manager keeps the same identity record.
- Use StatefulSets for identity continuity Run agent-backed workloads as StatefulSets when the monitoring relationship must survive rescheduling without forcing re-enrollment or record churn.
- Keep monitoring and application boundaries explicit Prefer sidecar deployment when you need the agent isolated from the application while still sharing logs or runtime data through a mounted volume.
Bottom line: Kubernetes pod churn can fragment monitoring unless the security agent keeps a persistent identity and state across restarts.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:41 pm
Persistent agent identity is the real control objective, not container uptime: Kubernetes can restart a pod in seconds, but that does not preserve the identity relationship a monitoring platform depends on. If registration keys, hostname, and configuration do not persist, the security control becomes blind to continuity. The practitioner conclusion is simple: treat the agent as a governed non-human identity, not as an interchangeable process.
A few things that frame the scale:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
A question worth separating out:
Q: How do sidecar and included deployment patterns differ for Kubernetes agents?
A: Sidecar deployment keeps the agent and application in separate containers with shared access to data, while included deployment bundles both into one image. Sidecar better preserves modularity, but included deployment can simplify rollout when teams accept tighter coupling.
👉 Read our full editorial: Kubernetes Wazuh agent identity persistence in ephemeral workloads