1. Introduction
Managing monitoring across a large Kubernetes cluster can quickly become overwhelming. Deploying Elastic Agent as a DaemonSet solves this by automatically placing an agent on every node no manual setup required.
Fleet makes management even simpler by giving you centralized control. Push policy changes, configure new integrations, and roll out updates across your entire infrastructure from one dashboard instead of configuring each agent individually.
This guide covers deploying a Fleet-managed Elastic Agent DaemonSet on OpenShift, with the minimal configuration needed to work within OpenShift’s security requirements.
We’ll also explore leader election a smart coordination mechanism where one agent handles cluster-wide tasks while others focus on local node data. This approach delivers comprehensive monitoring without unnecessary resource overhead, giving you full visibility with streamlined operations.
2. What is Fleet?
Fleet is Elastic’s centralized management layer for Elastic Agents. Instead of manually configuring each agent, you enroll them into Fleet, where you can apply policies, integrations, and updates from a single UI in Kibana.
- Without Fleet: every agent needs its own configuration.
- With Fleet: one policy can be applied across all agents.
When running Elastic Agents as a DaemonSet, Fleet ensures consistent configuration across all nodes, simplifying operations and scaling observability.
3. Steps for enrollment
3.1. Create a Service Account
Elastic Agent must interact with the Kubernetes API to collect cluster metadata such as pod, node, and namespace information. To enable this securely, you first need to create a dedicated Service Account in the namespace where the agent will run.
For OpenShift and Kubernetes, the recommended namespace is elastic-system. Although you can also use the default kube-system namespace, creating a dedicated elastic-system namespace keeps Elastic resources organized and separate from core Kubernetes components.
oc create namespace elastic-system
oc create serviceaccount elastic-agent -n kube-system
3.2. Apply Security Context Constraints (SCC)
In OpenShift, pods must run within the boundaries of Security Context Constraints (SCCs). By default, Elastic Agent requires elevated privileges to run correctly. To grant these permissions, bind the Service Account you created to an appropriate SCC.
oc adm policy add-scc-to-user hostaccess -z elastic-agent -n kube-system
This command links the elastic-agent Service Account with the hostaccess SCC, allowing it to collect the required data without being blocked by OpenShift’s security model.
3.3. Deploy the Fleet-Managed Elastic Agent DaemonSet
With the Service Account and SCC in place, the next step is to deploy Elastic Agent as a Fleet-managed DaemonSet.
- In Kibana, go to Fleet from the left navigation.
- Select the policy you want to use for your Kubernetes Elastic Agents.
- Scroll down to the command section and select Kubernetes and click on Download manifest.
- Copy the manifest file to your cluster and change name space if u want but by default namespace is kube-system.
5. In the manifest file there is flag FLEET_INSECURE by default its value is false.
- Default (no flag): The agent verifies the Fleet Server’s TLS/SSL certificate. If it’s signed by a trusted authority, communication is secure.
- With –insecure: Certificate validation is skipped, allowing connections to self-signed or untrusted certificates. This is acceptable for testing but should be avoided in production as it reduces security
6. After changing these Apply this manifest file on your master and this will apply automatically to all
kubectl apply -f elastic-agent-managed-kubernetes.yaml
Since this manifest deploys the Elastic Agent as a DaemonSet, it will automatically run on the master and all worker nodes in the cluster, giving you full coverage without further manual steps.
5. Conclusion
Running Elastic Agent as a Fleet-managed DaemonSet on OpenShift gives you complete, centrally managed observability with minimal setup. Service Accounts and SCCs handle OpenShift’s security model, Fleet ensures consistent policy management, and leader election prevents duplicate cluster-wide metrics. Together, these features provide a secure, scalable, and efficient monitoring foundation for your workloads.
Written by: Haris Ahmed
