Having spent the last few months wrestling with endpoint protection across a mix of on-premise bare-metal Kubernetes clusters, managed services in two different public clouds, and a stubborn legacy VM estate, I feel like I've run the gauntlet. The promise of a unified view and consistent policy enforcement is alluring, but the reality is often a patchwork of agents, conflicting daemonsets, and blind spots.
The core challenge, as I see it, isn't just about detecting threats, but about the *orchestration* of the security agent itself in a cloud-native, hybrid world. You need something that can deploy and manage itself consistently as:
* A DaemonSet on your k8s nodes (for the host runtime).
* An agent on your k8s worker pods (for container runtime security).
* A traditional agent on your VMs and bare-metal servers outside Kubernetes.
For the Elastic stack specifically, the Elastic Defend integration is the relevant component. Here's what I've found actually works, and where the friction points are:
**The Kubernetes Integration is Solid (Once Configured)**
The Helm chart for the Elastic Agent is the way to go. It handles the DaemonSet deployment and can be configured to tie into Fleet Server for centralized management. The key is ensuring your `elastic-agent` namespace has the appropriate tolerations and node selectors to hit all your node pools, including Windows nodes if you have them.
```yaml
# values.yaml snippet for the elastic-agent Helm chart
daemonset:
tolerations:
- key: "node-role.kubernetes.io/master"
operator: "Exists"
effect: "NoSchedule"
- key: "node-role.kubernetes.io/control-plane"
operator: "Exists"
effect: "NoSchedule"
nodeSelector:
kubernetes.io/os: linux
```
**The Hybrid "Fleet" Management Requires Careful Networking**
The Fleet Server (your management plane) needs to be reachable by *all* your agents, whether they're inside a private VPC, on-premise, or in another cloud. This often means:
* Exposing Fleet Server via a LoadBalancer with a stable, public IP (secured with TLS and API keys, of course).
* Or, establishing a site-to-site VPN/network mesh so agents can reach Fleet on an internal address.
* Configuring your `fleet.yml` in the agent deployment with the correct, reachable hostname.
**The Pitfalls I've Encountered:**
* **Resource Consumption:** The agent isn't lightweight. On smaller worker nodes, you need to pay close attention to CPU/Memory limits in the DaemonSet, or it can evict your actual workload pods.
* **Policy Consistency:** Creating a single policy in Fleet that correctly applies to both your Kubernetes hosts and your standalone VMs requires careful use of agent `tags` and conditionals in the policy assignment.
* **Data Ingestion Costs:** This is the big one. Enabling all the recommended event streams (especially on noisy nodes) can generate a staggering amount of data in Elasticsearch. You **must** tune what you collect from the start—focus on security events over system metrics unless you have a specific use case.
My current working setup uses the Elastic Agent via Fleet, with the Defend integration enabled, deployed across clusters via Helm (managed through GitOps/ArgoCD) and on VMs via the standalone package installer. The visibility is excellent, but the operational overhead and cost vigilance are non-trivial.
I'm curious to hear from others in similar hybrid trenches. How are you handling the network connectivity for Fleet? Have you found effective ways to filter event volume at the source, before it hits Elasticsearch?
kubectl apply -f
yaml is my native language