Fleet Security Audit and Auto-Remediation with Assets

Security audits that end in a PDF do not fix anything. This blueprint runs a closed audit-remediate loop over your whole fleet: it enumerates every io.kestra.plugin.ee.assets.VM asset in the Kestra catalog, checks each machine for a required endpoint security agent, stamps compliance_status and last_audit into the asset metadata, then immediately queries for the non-compliant machines and reinstalls the agent on them, resetting their status to compliant. The asset catalog is both the target list and the compliance record.

How it works

1. get_all_servers (io.kestra.plugin.core.debug.Return) fetches every VM asset with assets(type='io.kestra.plugin.ee.assets.VM').
2. audit_servers (io.kestra.plugin.core.flow.ForEach) loops over the fleet. get_server_info (io.kestra.plugin.core.execution.SetVariables) unpacks id, IP, env, OS, and Python version from each asset.
3. check_security_agent (io.kestra.plugin.scripts.shell.Script) simulates the probe, reporting the agent missing on srv-stg-01. Replace it with a real SSH check or an EDR API call.
4. update_compliance_status (io.kestra.plugin.core.debug.Return) re-registers each VM asset with compliance_status (via a ternary expression), last_audit: {{ now() }}, and the carried-over inventory metadata.
5. fleet_remediation (io.kestra.plugin.core.flow.Sequential) closes the loop: find_non_compliant queries assets(metadata={'compliance_status': 'non-compliant'}), then install_security_agent iterates over the offenders and ssh_install (io.kestra.plugin.scripts.shell.Commands) reinstalls the agent, resetting compliance_status: compliant and stamping remediated_at.
6. A daily Schedule trigger (disabled by default) and a webhook secured by AUDIT_WEBHOOK_KEY provide automation entry points.

What you get

• A full-fleet audit with per-server task runs and logs.
• Compliance state stored as queryable asset metadata, not a report file.
• Automatic remediation in the same execution, with remediated_at evidence.
• A repeatable pattern for any check-then-fix policy across cataloged infrastructure.

Who it's for

• Security engineers enforcing endpoint agent coverage across VM fleets.
• SRE and platform teams automating compliance instead of chasing tickets.
• Auditors who need timestamps and execution history rather than screenshots.

Why orchestrate this with Kestra

Scanners find gaps; ticket queues let them age. Kestra collapses detection and remediation into one governed workflow: the assets() function supplies live fleet state, ForEach gives per-machine isolation and retries, and asset metadata becomes an auditable compliance ledger updated transactionally with each fix. Schedules make it continuous and the execution history proves every audit and every remediation, including who or what triggered them.

Prerequisites

• A Kestra Enterprise Edition instance (Assets are an EE feature).
• VM assets with ip_address, env, os, and python_version metadata, for example registered by the asset-provision-servers blueprint.
• Real connectivity to the servers when you replace the simulated check and install.

Secrets

• AUDIT_WEBHOOK_KEY: shared secret guarding the Webhook trigger, for example called by GitHub Actions.

Quick start

1. Add the AUDIT_WEBHOOK_KEY secret to your Kestra instance.
2. Run asset-provision-servers so VM assets exist in the catalog.
3. Import this blueprint and execute it manually to watch the audit and remediation loop.
4. Enable the daily_audit schedule to make the audit continuous.

How to extend

• Replace the simulated probe with io.kestra.plugin.fs.ssh.Command or your EDR vendor's API.
• Alert a Slack channel with the non-compliant list before remediating.
• Add a Pause approval before remediation in production environments.
• Extend the audit to more checks (open ports, kernel version) and store each result as metadata.

Links

• Kestra Assets documentation: https://kestra.io/docs/enterprise/governance/assets
• Shell script plugin docs: https://kestra.io/plugins/plugin-script-shell