CIS Control 1.6.4: Assess and Remediate /etc/motd Permissions over SSH

Implement a single CIS benchmark control as a reusable, callable flow. This blueprint covers CIS Ubuntu control 1.6.4 (ensure access to /etc/motd is configured): it reads the expected stat output from the Kestra KV store, SSHes into the target host to capture the current state, and either reports compliance or fixes ownership and permissions in place. A parent scan flow can invoke it per host and aggregate the returned complianceStatus output.

How it works

1. The getConfiguration task (io.kestra.plugin.core.kv.Get) loads the expected stat -Lc output for /etc/motd, stored in the KV store under the flow id key so each control owns its baseline.
2. The assessControl task (io.kestra.plugin.fs.ssh.Command) connects with authMethod: PUBLIC_KEY and captures the live ownership/permission string, emitting it as a task output through the ::{"outputs":...}:: convention.
3. The checkStatus task (io.kestra.plugin.core.flow.Switch) compares the observed value against the baseline: a match, or an absent file, is Compliant.
4. On mismatch, the doRemediate task (io.kestra.plugin.core.flow.If) checks the remediateControls input; if true, remediateControl runs chown root:root and chmod u-x,go-wx on the file, otherwise the flow returns Not Compliant.
5. The complianceStatus flow output coalesces whichever branch ran, so callers always get a single string verdict.

What you get

• A self-contained compliance control with assess, decide, and remediate stages.
• A KV-stored baseline you can update without editing the flow.
• A toggle (remediateControls) to run in audit-only or auto-fix mode.
• A clean complianceStatus output for aggregation by a parent scan flow.

Who it's for

• Security and platform engineers automating CIS benchmark enforcement on Linux fleets.
• Compliance teams that need repeatable, logged evidence of control state per host.
• SREs replacing ad hoc hardening scripts with governed, per-control workflows.

Why orchestrate this with Kestra

Hardening scripts run once and leave no trail. As a Kestra flow, every assessment is an execution with logs, timings, and the exact observed value; remediation is an explicit, toggleable branch rather than a side effect; and the control becomes composable, so a scan orchestrator can fan out dozens of controls in parallel and retrigger a single failed control without rerunning the whole benchmark.

Prerequisites

• A Linux target reachable over SSH with a user allowed to sudo chown/chmod.
• A KV entry keyed by this flow's id containing the expected stat output string.

Secrets

• SSH_VM_USER: SSH username for the target host.
• SSH_PRIVATE_KEY: private key used for public key authentication.

Quick start

1. Add the secrets above to your Kestra namespace.
2. Store the compliant stat string in the KV store under the key cis-control-motd-permissions.
3. Execute with your host's IP in ipAddress and remediateControls: false for a dry audit.
4. Re-run with remediation enabled to fix non-compliant hosts.

How to extend

• Clone this flow per CIS control, changing only the assess and remediate commands.
• Call it from a parent scan flow with io.kestra.plugin.core.flow.Subflow and aggregate complianceStatus values.
• Push results to a compliance dashboard or SIEM via io.kestra.plugin.core.http.Request.
• Loop over an inventory with io.kestra.plugin.core.flow.ForEach to scan a whole fleet.

Links

• SSH Command plugin docs: https://kestra.io/plugins/plugin-fs/ssh/io.kestra.plugin.fs.ssh.command
• KV store docs: https://kestra.io/docs/concepts/kv-store