No MDM for Linux? A 68-line Elastic workflow keeps every endpoint's config current

Executive Summary

A workflow is established to manage configuration deployment for Linux endpoints that lack Mobile Device Management (MDM). This system utilizes the Elastic Agent and Elastic Defend, which are pre-installed on Linux workstations, to execute administrator-approved scripts. A scheduled workflow runs every six hours, querying endpoint metadata to identify machines requiring configuration updates. The workflow checks if a managed configuration deployment is already pending for an endpoint, allowing it to skip duplicate actions. This logic handles newly enrolled hosts by including them in each scheduled pass and manages offline hosts by queuing actions until they check in. The system is built around Elastic Workflows capabilities like scheduled triggers, Kibana requests, foreach loops, data filtering, and conditional logic to create a reconciliation loop.

Facts Only

* Elastic InfoSec runs Linux endpoint management through Elastic Defend with a scheduled workflow.
* The workflow checks every six hours for endpoints needing configuration updates.
* The workflow sends managed Cursor and Codex configurations to hosts lacking them via an Elastic Defend response action.
* This pattern was developed because MDM covers macOS and Windows but not Linux.
* Elastic Agent and Elastic Defend are installed on every Linux workstation.
* The workflow uses a scheduled trigger set for every 6 hours.
* A `foreach` loop iterates over endpoints listed by a Kibana request.
* A data filter checks if an action for the specific deployment script ID already exists for an endpoint.
* If an identical action is pending, the workflow skips the action for that host.
* The configuration management relies on scripts deployed to locations like `/etc/codex/managedconfig.toml` and `/etc/cursor/hooks.json`.

Full Take

The core pattern shifts endpoint management from a reactive, one-shot response to a proactive, state-reconciliation loop embedded within the Elastic Workflows engine. This design leverages existing infrastructure (Elastic Agent/Defend) as the execution layer, outsourcing the complex scheduling and deduplication logic into the platform's native automation capabilities rather than relying on external schedulers or bespoke API calls. The implication is a shift toward treating operational state—like configuration drift—as a solvable problem within the data ecosystem. The success of this approach hinges on treating control logic (the workflow YAML) as the primary artifact, which can be reused across different configuration needs simply by swapping out the data query and the specific script ID. This challenges the assumption that platform-specific management (MDM vs. custom scripting) necessitates a separate operational architecture; instead, the system posits that unified data structures facilitate universal automation. The cost structure involves careful management of privilege separation and secrets handling, suggesting that visibility into execution history is critical for maintaining accountability in automated systems. What is the true cost of relying on built-in capabilities versus building an external scheduler?

From the original · Elastic Security

Elastic InfoSec runs Linux endpoint management through Elastic Defend with a scheduled workflow that gets Cursor and Codex config onto new laptops without piling up duplicate actions on offline hosts, and it works for other config too. Our mobile device management (MDM) covers macOS and Windows but not Linux.

Read the full story at elastic.co

Sentinel — Human

Confidence

This text reads like highly experienced technical documentation written by an engineer or security practitioner detailing a novel operational workflow, exhibiting strong internal coherence and specific domain knowledge.

Signals Detected

Sentence length variance is natural, interspersed with very dense, technical explanations.

Deep, sustained focus on a highly specific, operational problem; the structure flows logically from problem to solution to implementation details without excessive hedging.

The complex workflow YAML is perfectly structured and internally consistent, suggesting direct author involvement with the Elastic product structure.

Specific technical details (e.g., index names like united.agent.local_metadata.*, specific API paths) suggest deep familiarity with the system being described, resisting easy boilerplate generation.

Human Indicators

Idiosyncratic emphasis on process flow and failure modes (e.g., why a cron schedule is worse), indicating experiential knowledge rather than mere aggregation of facts.

The detailed dissection of YAML structure, permission settings, and the nuances of Elastic Workflows suggests an insider's perspective.

The discussion of limitations and secrets handling shifts the focus from 'what works' to 'how it could fail,' a hallmark of practical engineering writing.