CIS Compliance Scan and Remediation Orchestrator

Run a CIS benchmark section as a governed scan. This orchestrator fans out individual control flows (each an assess/remediate unit) against a target host, collects their complianceStatus outputs, and logs a verdict per control. It ships with two optional triggers: a webhook for on-demand scans from an ITSM tool, and a Flow trigger that scans every VM automatically the moment a provisioning flow finishes, closing the gap between "machine exists" and "machine is hardened".

How it works

1. The section_1_6 task (io.kestra.plugin.core.flow.Parallel with concurrent: 1) hosts one Sequential branch per control. Branches are modeled in a Parallel container deliberately: any single control can be retriggered from the UI without rerunning its siblings.
2. Each branch calls a control flow via io.kestra.plugin.core.flow.Subflow with wait: true and transmitFailed: true: run_control_1_6_4 invokes cis-control-motd-permissions and run_control_1_6_5 invokes cis-control-etc-issue-permissions.
3. The host comes from {{ trigger.body.ipAddress ?? inputs.ipAddress }}, so the same flow serves webhook-driven and manual scans.
4. After each control, a io.kestra.plugin.core.log.Log task records the returned complianceStatus verdict.
5. The scanRequestWebhook trigger (io.kestra.plugin.core.trigger.Webhook) and the postVMCreation trigger (io.kestra.plugin.core.trigger.Flow with a preconditions block on the provisioning flow's SUCCESS state) are included disabled; enable whichever entry point you need.

What you get

• A scan orchestrator that composes per-control flows instead of one monolithic script.
• Per-control retriggering: fix a flaky SSH session on one control without rescanning everything.
• A single remediateControls toggle propagated to every control (audit vs enforce).
• Event-driven hardening of new VMs via the flow trigger.

Who it's for

• Security engineers operationalizing CIS benchmarks across Linux estates.
• Platform teams who want every provisioned VM scanned before it takes traffic.
• Compliance owners needing per-control execution evidence.

Why orchestrate this with Kestra

Benchmark scripts are all-or-nothing: one failing check means rerunning the whole run, and results live in a log file. Kestra decomposes the benchmark into subflows with real dependency semantics, parallel fan-out, per-branch retries, and typed outputs you can aggregate. The Flow trigger with preconditions turns compliance from a scheduled afterthought into an automatic step of the provisioning lifecycle.

Prerequisites

• The companion control blueprints deployed in the same namespace: cis-control-motd-permissions and cis-control-etc-issue-permissions (adjust flowId values if you rename them).
• SSH access from the Kestra worker to the target hosts (the control flows use SSH_VM_USER and SSH_PRIVATE_KEY secrets).

Secrets

• CIS_SCAN_WEBHOOK_KEY: shared key guarding the webhook trigger (only needed if you enable it).

Quick start

1. Deploy the two control blueprints, then this orchestrator, in the same namespace.
2. Add the SSH secrets required by the control flows, and the webhook key if you enable the webhook.
3. Execute manually with a target ipAddress and remediateControls: false for an audit pass.
4. Enable the postVMCreation trigger and point its flowId at your provisioning flow to scan new VMs automatically.

How to extend

• Add more branches for additional CIS controls; each is just another Subflow call.
• Aggregate all verdicts into a summary report and post it with io.kestra.plugin.notifications.slack.SlackIncomingWebhook.
• Loop over a host inventory with io.kestra.plugin.core.flow.ForEach for fleet-wide scans.
• Store scan results in a database for compliance trend dashboards.

Links

• Subflow task docs: https://kestra.io/plugins/core/tasks/flow/io.kestra.plugin.core.flow.subflow
• Flow trigger docs: https://kestra.io/plugins/core/triggers/io.kestra.plugin.core.trigger.flow