← Back to LEA Platform | Full Site Content | All Insight Articles
Version: 2.0.2 | Publisher: GSR IT | Contact: lea@gsr-it.com
This page contains the complete LEA Platform documentation in static HTML format, designed for AI assistants, search engine crawlers, and automated agents. No JavaScript is required to read this content.
LEA (Lateral Execution Agent) is a powerful, enterprise-grade platform designed for orchestrating and automating configuration management and compliance across distributed multi-platform environments. Built with security and scalability at its core, LEA enables organizations to define compliance rules, monitor system state in real-time, and automatically remediate drift across their infrastructure spanning Linux, Windows, and macOS systems.
With LEA, you define what your systems should look like using JSON-based rules, and LEA continuously ensures they stay that way—detecting deviations, alerting stakeholders, and optionally remediating issues automatically.
The LEA agent installs seamlessly on all major operating systems and distributions using a single command. Works on Linux (all distributions), Windows, and macOS.
curl -fsSL https://get.lea-platform.io/agent.sh | bash
For environments preferring agentless operation, LEA supports deployment through all major client orchestration tools including Ansible, Puppet, Chef, SaltStack, and equivalent configuration management platforms.
LEA agents are lightweight (minimal resource footprint) and self-updating. Once deployed, agents automatically connect to the controller and begin executing assigned rules based on group membership.
The central control plane responsible for rule management, agent coordination, and real-time monitoring.
Lightweight agents deployed on target hosts for rule execution and compliance monitoring.
PostgreSQL database for persistent storage of all platform data: rule definitions, execution history, client inventory, group configurations, audit logs, user accounts and permissions.
Rules mapped to ISO 27001, NIST 800-53, PCI DSS, CIS benchmarks, NCSC:PQC, EU:DORA, and BIS:QuantumRoadmap.
Real-time visibility into client status, rule compliance, and comprehensive troubleshooting capabilities with live actions and advanced metadata-based filtering.
The Compliance page serves as your central command center for monitoring all managed clients, their compliance status, and provides powerful tools for investigation and live troubleshooting.
| Column | Description |
|---|---|
| Client Name | Unique identifier for the managed endpoint |
| Status | Verified (green) or Unverified (red) |
| Distribution | Linux distribution (Ubuntu, Rocky, Alpine, Oracle, etc.) |
| Version | Full distribution version with codename |
| IP Address | Primary network interface IP |
| Last Seen | Timestamp of last agent check-in |
Click the expand arrow on any client row to view inline details including:
Comprehensive view of client information, execution history, logs, and live actions. Available tabs:
Lists all rule executions for this client with their outcomes. Each execution shows the rule name, execution timestamp, return code, and whether the result matched expected values.
Complete chronological log of all command executions on this client. Includes scheduled rule runs, manual executions, and system-triggered checks.
Raw logs from the LEA agent running on the client. Essential for debugging connectivity issues, understanding agent behavior, and diagnosing problems. Logs can be searched and filtered by severity level.
Real-time debug stream from the agent. When enabled, shows live verbose output from the agent including rule processing, network communications, and internal state changes.
Execute ad-hoc commands directly on the client in real-time. Perfect for troubleshooting, verification, and one-off administrative tasks without creating permanent rules.
Shows all groups this client belongs to, including groups inherited through nested group relationships. Helps understand which rules apply to this client based on group membership.
Execute commands on clients in real-time for troubleshooting and verification.
Filter clients by system attributes collected from each endpoint. Dynamic Tags from rule outputs can be used for filtering and grouping. See the Search & Filter section for full details.
Granular visibility into rule execution status across all clients, showing detailed output, verification results, and historical execution data for each client-rule combination.
While the Compliance Monitoring page shows aggregated status per client, the Execution page drills down to show individual execution results for every rule on every client—essential for troubleshooting specific failures and tracking remediation history.
| Column | Description |
|---|---|
| Client name | The endpoint where the rule was executed |
| Rule | The name of the rule that was executed |
| Status | Verified (green) or Unverified (red) |
| Stdout | Standard output from the command execution |
| Stderr | Standard error output (if any) |
| RC | Return code from the command (0 typically indicates success) |
| Time | Timestamp of the execution |
When a rule execution fails verification, expand the row to see detailed information:
The Standard Output section includes a search field to quickly locate relevant values and highlight all occurrences.
Track compliance progression over time for any client-rule combination.
Powerful search and filtering capabilities to quickly locate clients and executions using text search, status filters, and advanced metadata-based filtering.
The advanced metadata filtering system is shared between the Compliance and Execution pages. The Execution page includes an additional Rule Name search field for filtering by specific rules.
Filter clients and executions by system attributes collected from each endpoint.
| Field | Description | Example Values |
|---|---|---|
| Distribution | Linux distribution name | Ubuntu, Rocky, Oracle, Alpine |
| Version | Distribution version with codename | 22.04 (Jammy), 9.5 (Blue Onyx) |
| Kernel | Linux kernel version | 6.8.0-49-generic, 5.14.0-503.el9 |
| Architecture | CPU architecture | x86_64, aarch64 |
| System Type | Operating system type | Linux |
| LEA Version | Installed LEA agent version | 2.0.2, 2.0.1 |
Define and manage compliance and configuration rules for your infrastructure.
A rule is a compliance or configuration definition that will be checked on clients assigned with this rule (via group membership) and verified/remediated in case the detected status is non-compliant. Rules enable automated compliance monitoring and enforcement across your infrastructure.
Understanding the three main components of a rule:
The command executed to check the current state of the system.
Defines the checks required to pass for this rule to be marked as 'compliant'.
The command executed to fix non-compliant states automatically. Same command types as validation (shell script, internal agent function, uri_sh).
The Command Info Key (tag) field enables LEA's Dynamic Tags feature. When specified, the rule's stdout output is automatically captured and stored as metadata on each client that executes the rule.
How It Works:
Example use cases: hostname, mac_addr, package_inventory, process_count.
Dynamic Tags can be used for advanced filtering in the Compliance and Execution pages and for automatic group allocation using JSONPath expressions.
The Parameters section allows you to define variables and secrets that can be referenced within your rule commands.
Security Note: Secret values are masked in the UI and encrypted during transmission. Use Environment Var type for any sensitive data that should not be visible in logs or audit trails.
LEA allows you to define multiple validation commands within a single rule, each targeting different operating systems or Linux distributions. This creates universal rules that adapt to the target system.
Each validation block includes: Field (command type), Rule (actual command), Systems (target OS: Linux, Darwin/macOS, Windows), Target Distributions (specific Linux distributions).
Example: Cross-Platform Process Check — Validation #1 (Linux): ps -ef, Validation #2 (macOS/Darwin): ps -ax, Validation #3 (Windows): tasklist
The LEA agent automatically detects the operating system and distribution, then executes only the matching validation command.
Supported distributions: Linux, Darwin, Windows, Alpine Linux, Oracle Linux Server, Rocky Linux, Ubuntu, openSUSE Leap.
LEA includes a powerful Regular Expression Builder to help you create and validate regex patterns for verification rules.
Common Regex Patterns: .* (any chars), .+ (one or more), \d+ (digits), \w+ (word chars), [a-zA-Z]+ (letters), ^/$ (line boundaries), (group) (capturing), [abc] (character class), \s/\S (whitespace).
The JSON Tools dialog provides powerful capabilities for viewing and managing your rules in JSON format.
{
"name": "Blacklisted Offensive Tools Not Running",
"description": "Ensures no known offensive security tools...",
"active": true,
"category": "integrity",
"cycle": 3600,
"cmd": {
"validation": [
{ "command": "ps -ef", "system": ["Linux"], "distribution": [] },
{ "command": "ps -ax", "system": ["Darwin"], "distribution": [] },
{ "command": "tasklist", "system": ["Windows"], "distribution": [] }
]
}
}
LEA provides a powerful tag-based filtering system to navigate large rule sets. Filter rules by multiple criteria including compliance category, risk level, environment, priority, and compliance standards.
When a rule's validation or remediation command requires elevated privileges, use lea_priv_wrapper.sh — a strict whitelist gate that replaces broad sudo access with per-command authorization.
In the rule's validation or remediation command field, prefix the command with the wrapper and a COMMAND_KEY:
sudo /usr/local/sbin/lea_priv_wrapper.sh systemctl_status ssh.service sudo /usr/local/sbin/lea_priv_wrapper.sh sysctl_get net.ipv4.ip_forward sudo /usr/local/sbin/lea_priv_wrapper.sh apt_install auditd
The wrapper accepts a COMMAND_KEY as the first argument and one validated argument as the second. Each argument is validated against a per-command regex before execution. Only whitelisted operations can run. All invocations are logged to syslog tagged lea_priv_wrapper.
For full installation and sudoers setup details, see the LEA Agent section.
Organize managed clients and assign validation rules with flexible targeting.
Groups allow you to organize managed clients (hosts) and assign specific validation rules to them. This enables targeted compliance and security checks across different segments of your infrastructure. Groups can be static (manually selected hosts) or dynamic (automatically matched using JSONPath expressions on client metadata).
Groups also support nesting, allowing you to include all clients or rules from another group, creating hierarchical configurations that simplify policy management.
JSONPath Examples:
$.clients[?(@.os_type == 'Linux')] — Matches all Linux clients $.clients[?(@.environment == 'production')] — Matches all production hosts
Nested groups allow you to include all clients or rules from another group. When you add a nested group, all current members of that group will be automatically included in this group.
Track compliance events, client state changes, and administrative activities.
LEA provides comprehensive audit capabilities divided into two main views:
The Webhook Audit view displays all incoming events from LEA agents, including compliance state changes, heartbeats, and other client communications.
Total Entries, Webhook Events, Compliance Events, Success Rate
| Column | Description |
|---|---|
| Client Name | The hostname or identifier of the reporting agent |
| Timestamp | When the event occurred (sortable, descending by default) |
| Action | The type of event (compliance, webhook) |
| Method | HTTP method used for the webhook call (if applicable) |
| Response | HTTP response code (e.g., 200 = success) |
Click the arrow next to any entry to expand and view the full request data, showing current and previous state for compliance tracking.
The System Audit view records all administrative actions performed within LEA, including database operations like creating, updating, or deleting records.
Total Entries, Inserts, Updates, Deletes
| Column | Description |
|---|---|
| Timestamp | When the operation occurred (sortable) |
| Action | Database operation type (UPDATE, SELECT, INSERT, DELETE) |
| Table Name | The database table affected (e.g., client_groups, licenses) |
| Record Name | Human-readable identifier of the affected record |
| Actor | Username of the user who performed the action |
| Request ID | Unique identifier for the request (useful for correlation) |
When you expand an UPDATE entry, LEA displays the changes in a diff format showing removed values in red and added values in green.
Configure data retention, webhooks, SSO integration, licensing, user management, and platform-wide preferences.
The Settings page is the central hub for configuring LEA's operational parameters, integrations, and system behavior. Administrators can manage data retention policies, webhook integrations, Single Sign-On (SSO), licensing, and user accounts.
| Setting | Description |
|---|---|
| Audit Retention (Days) | How long to keep audit logs |
| Execution Retention (Days) | How long to keep execution results |
| Client Inactive Time (Days) | Mark clients inactive after this period |
| Execution Inactive Time (Days) | Mark executions inactive after this period |
Automatic purge options: Automatically purge old audit logs; Automatically purge old executions. Purge runs periodically to maintain database performance and storage efficiency.
Webhooks allow LEA to send real-time notifications to external systems when compliance events occur. Integrate with SIEM tools, ticketing systems, or custom automation workflows.
| Field | Description |
|---|---|
| Name | Descriptive name for the webhook (e.g., "Cisco ISE") |
| Webhook URL | The endpoint URL to receive notifications |
| Key | Authentication key or username for the webhook endpoint |
| Password | Authentication secret (stored securely, not displayed) |
| Type | Webhook type (Generic, Slack, Teams, etc.) |
| Groups | Select which client groups trigger this webhook |
| SSL Verify | Enable/disable SSL certificate verification |
LEA supports Single Sign-On via Keycloak, enabling centralized user management, multi-factor authentication, and integration with enterprise identity providers (LDAP, Active Directory, SAML, OIDC).
| Field | Description |
|---|---|
| Provider | SSO provider type (e.g., Keycloak) |
| Provider URL | The base URL of your SSO provider |
| Backend Provider URL | SSO service URL as seen from backend |
| Realm | Realm or tenant identifier in your SSO provider |
| Client ID | OAuth client identifier (e.g., "lea-platform") |
| SSO Display Name | Display name for SSO login button |
| Redirect URI | OAuth redirect URI |
Current license details: Status, License ID, Customer Name, Customer Email, Installed At, Valid Until, Days Remaining, Max Clients, Max Rules, Features (gsr_sso, lea_agent, lea_console, lea_platform).
Complete RESTful API documentation with OpenAPI support, advanced filtering, and granular permissions.
LEA provides a comprehensive RESTful API built on PostgREST, offering automatic OpenAPI documentation, powerful filtering capabilities, and granular permission controls. All API requests return JSON responses.
https://your-lea-controller.example.com/api/* (data endpoints) | /lea/* (platform endpoints)All API endpoints require authentication. Unauthenticated requests receive a 401 Unauthorized response.
POST /lea/authenticate_api_from_token Headers: Content-Type: application/json Authorization: Bearer <SSO_TOKEN>
curl -X GET \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <YOUR_TOKEN>" \ https://lea-controller.example.com/api/clients
LEA automatically generates an OpenAPI 3.0 specification at GET /api/.
| Operator | Meaning |
|---|---|
| eq | Equals |
| neq | Not equals |
| like | Pattern match (use * for wildcards) |
| ilike | Case-insensitive pattern match |
| in | Match any in list |
# Filter by exact value GET /api/clients?verified=eq.true # Case-insensitive search with wildcards GET /api/clients?name=ilike.*production* # Multiple IDs GET /api/cmds?id=in.(1,2,3,4,5) # Pagination and ordering GET /api/clients?order=name.asc&offset=0&limit=100 # Select specific columns GET /api/clients?select=id,name,verified,active # Get count with exact header GET /api/clients?select=count Header: Prefer: count=exact # Metadata filtering (Dynamic Tags) GET /api/clients?cmd_info->os_version->>stdout=eq.Ubuntu 22.04
LEA implements row-level security (RLS) and role-based access control.
| Role | Read | Write | Delete | Admin |
|---|---|---|---|---|
| Admin | ✓ | ✓ | ✓ | ✓ |
| Operator | ✓ | ✓ | ✓ | — |
| Viewer | ✓ | — | — | — |
| Auditor | ✓ | — | — | — |
| Method | Endpoint | Description |
|---|---|---|
| GET | /api/clients | List all clients with basic information |
| GET | /api/clients_verified | Clients with computed verification status, active state, and group info |
| GET | /api/clients_verified_with_group?group_id=eq.{id} | Clients filtered by group membership |
| GET | /api/client_effective_groups?client_id=eq.{id} | All groups a client belongs to (including nested parents) |
| DELETE | /api/clients?id=in.({ids}) | Bulk delete clients by ID |
| GET | /api/client_logs?client_id=eq.{id} | Agent log entries for a specific client |
| Method | Endpoint | Description |
|---|---|---|
| GET | /api/cmds | List all rules with full configuration |
| GET | /api/cmds_with_verification | Rules with computed verification status |
| GET | /api/cmds?id=eq.{id} | Get single rule by ID |
| POST | /api/cmds | Create new compliance rule |
| PATCH | /api/cmds?id=eq.{id} | Update existing rule |
| DELETE | /api/cmds?id=eq.{id} | Delete rule |
| GET | /api/cmds?select=cmd_info_key&cmd_info_key=neq.none | Available tag names |
| Method | Endpoint | Description |
|---|---|---|
| GET | /api/client_groups | List all client groups |
| GET | /api/client_groups_view | Groups with computed client counts |
| GET | /api/client_groups?id=eq.{id} | Get single group by ID |
| POST | /api/client_groups | Create new client group |
| PATCH | /api/client_groups?id=eq.{id} | Update existing group |
| DELETE | /api/client_groups?id=eq.{id} | Delete group |
| Method | Endpoint | Description |
|---|---|---|
| GET | /api/latest_cmd_results_all | Latest execution result per client/rule combination. Filters: verified, clients_id, cmd_id, client_name, cmd_name |
| GET | /api/latest_cmd_results_with_group?group_id=eq.{id} | Results filtered by group |
| GET | /api/cmd_results?clients_id=eq.{clientId}&cmd_id=eq.{cmdId} | Execution history for specific client/rule |
| GET | /api/cmd_results?id=eq.{id} | Single execution result with full output |
| GET | /api/rpc/cmd_results_timeseries?p_hours={hours}&p_points={points} | Aggregated compliance data for charting |
| DELETE | /api/cmd_results_max_ts?clients_id=in.({ids})&cmd_id=in.({ids}) | Bulk delete execution results |
| Method | Endpoint | Description |
|---|---|---|
| GET | /api/audit_log | System audit log entries. Filters: action, table_name, actor, request_id |
| GET | /api/webhook_audit | Webhook delivery attempts. Filters: action, client_id, response |
| GET | /api/cmds_changed_log | Recent rule changes for notification feeds |
| Method | Endpoint | Description |
|---|---|---|
| GET | /api/settings_ui?name=eq.settings_front | Platform UI/UX settings |
| PATCH | /api/settings_ui?name=eq.settings_front | Update settings (Admin required) |
| GET/POST/PATCH/DELETE | /api/settings_webhook | Webhook CRUD operations |
| GET/POST/PATCH/DELETE | /api/users | User account management |
| GET | /lea/license | Current license details |
| GET | /lea/license?request=true | Generate license request |
| POST | /lea/license | Upload license |
| GET | /lea/version | Platform version (no auth required) |
| Status | Meaning |
|---|---|
| 200 | Success |
| 201 | Created |
| 204 | No Content (successful write with no body) |
| 400 | Bad Request — Invalid query or body |
| 401 | Unauthorized — Missing or invalid token |
| 403 | Forbidden — Insufficient permissions |
| 404 | Not Found — Resource doesn't exist |
| 500 | Server Error — Check logs for details |
# Example error response
{
"error": "Permission denied",
"message": "User does not have access to this resource",
"details": "RLS policy violation on table 'cmds'",
"hint": "Check user roles and permissions"
}
The LEA Agent is a lightweight security monitoring client that connects to a LEA server, executes validation commands, and reports results. It ships as two binaries:
| Binary | Purpose |
|---|---|
lea-agent | Watchdog — starts and monitors the runner, auto-restarts on crash, manages version fallback |
lea-agent-runner | Runner — connects to the LEA server, runs commands, sends results |
In normal operation you only interact with lea-agent (the watchdog). It finds and launches the runner automatically.
Place both binaries in the same directory alongside lea.conf, then run:
./lea-agent
The LEA Agent uses a two-component architecture for maximum reliability and self-healing capabilities:
--help Show help and exit --version Show version information and exit --dry Show which runner binary would be used, without starting it --runner-version=X.Y.Z Pin to a specific runner version (e.g. 1.2.3) --force-cmd=COMMAND Run the agent once for one specific command, then exit --privileged Allow the watchdog to run as root / SYSTEM --user=USERNAME Run the runner as this user (Linux/macOS only) --group=GROUPNAME Run the runner as this group (Linux/macOS only) --install-service Install lea-agent as a Windows service (Windows only) --uninstall-service Remove the Windows service registration (Windows only)
--help Show help and exit --version Show version information and exit --show-config Print resolved configuration and exit --force-cmd=COMMAND Execute one specific server command, then exit --privileged Allow running as root / SYSTEM
Configuration is read from the following sources in priority order (highest first):
./lea.conf, conf/lea.conf, /etc/lea.conf| Key | Default | Description |
|---|---|---|
| LEA_SERVER_URL | https://lea.gsr-it.com/lea | LEA server endpoint |
| LEA_DEBUG | 0 | Debug logging (0 = off, 1 = on) |
| LEA_INTERVAL | 30 | Server poll interval in seconds |
| LEA_COMMAND_TIMEOUT | 60 | Max seconds a command may run |
| LEA_SKIP_SSL_VERIFY | false | Skip TLS certificate verification |
| LEA_USER | (current user) | Run runner as this OS user (watchdog only, Linux/macOS) |
| LEA_GROUP | (current group) | Run runner as this OS group (watchdog only, Linux/macOS) |
# LEA Agent Configuration File LEA_SERVER_URL=https://lea.example.com/lea LEA_SKIP_SSL_VERIFY=false LEA_DEBUG=0 LEA_INTERVAL=30 LEA_COMMAND_TIMEOUT=60 LEA_USER=lea LEA_GROUP=lea
LEA_SKIP_SSL_VERIFY=true in testing or development environments. In production, always use valid SSL certificates.
Create /etc/systemd/system/lea-agent.service:
[Unit] Description=LEA Security Agent After=network.target [Service] ExecStart=/opt/lea/lea-agent WorkingDirectory=/opt/lea Restart=on-failure User=lea Group=lea StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target
sudo systemctl daemon-reload sudo systemctl enable --now lea-agent sudo journalctl -u lea-agent -f # follow logs
Create /Library/LaunchDaemons/com.lea.agent.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key> <string>com.lea.agent</string>
<key>ProgramArguments</key> <array><string>/opt/lea/lea-agent</string></array>
<key>WorkingDirectory</key> <string>/opt/lea</string>
<key>RunAtLoad</key> <true/>
<key>KeepAlive</key> <true/>
<key>StandardOutPath</key> <string>/opt/lea/lea-agent.log</string>
<key>StandardErrorPath</key> <string>/opt/lea/lea-agent.log</string>
</dict>
</plist>
sudo launchctl load -w /Library/LaunchDaemons/com.lea.agent.plist
Run the following commands in an elevated (Administrator) terminal:
# Install (auto-start at boot) .\lea-agent.exe --install-service # Start immediately Start-Service LEAAgent # Stop Stop-Service LEAAgent # Remove .\lea-agent.exe --uninstall-service
You can also manage the service via services.msc — it appears as LEA Agent.
Log file: when running as a service, all output is written to lea-agent.log in the same directory as lea-agent.exe. To follow it in PowerShell:
Get-Content -Wait .\lea-agent.log
When run interactively (not as a service), output goes to stderr as normal.
The watchdog scans its own directory for all lea-agent-runner* binaries and selects the highest semantic version. To deploy a new runner version, drop the new binary alongside the old one — the watchdog will pick it up on next restart.
If the runner crashes within 30 seconds of starting, the watchdog falls back to the next lower version automatically.
| Code | Meaning |
|---|---|
| 0 | Success |
| 1 | Running as root without --privileged |
| 2 | Configuration error |
| 3 | Certificate error |
| 4 | Network / connectivity error |
| 5 | Command execution error |
| 99 | Unknown error |
lea_priv_wrapper.sh is a privileged command wrapper script for the LEA agent. It acts as a strict whitelist gate for all operations that require root privileges on the monitored machine. Instead of granting the lea service account broad sudo rights, a single sudoers entry points exclusively to this script.
cp lea_priv_wrapper.sh /usr/local/sbin/lea_priv_wrapper.sh chown root:root /usr/local/sbin/lea_priv_wrapper.sh chmod 750 /usr/local/sbin/lea_priv_wrapper.sh
Add a single entry to /etc/sudoers.d/lea:
lea ALL=(root) NOPASSWD: /usr/local/sbin/lea_priv_wrapper.sh
Validate with visudo -c after saving.
sudo /usr/local/sbin/lea_priv_wrapper.sh systemctl_status ssh.service sudo /usr/local/sbin/lea_priv_wrapper.sh sysctl_get net.ipv4.ip_forward sudo /usr/local/sbin/lea_priv_wrapper.sh apt_install auditd
View all supported keys: /usr/local/sbin/lea_priv_wrapper.sh --help
lea_priv_wrapper.