CIS Control 1.6.5: Assess and Remediate /etc/issue Permissions over SSH

Implement CIS Ubuntu control 1.6.5 (ensure access to /etc/issue is configured) as a reusable, callable compliance flow. It reads the expected stat output from the Kestra KV store, SSHes into the target host to capture the live state, and either reports compliance or fixes ownership and permissions in place. Pair it with its sibling control flows and a scan orchestrator to run whole benchmark sections per host.

How it works

1. The getConfiguration task (io.kestra.plugin.core.kv.Get) loads the expected stat -Lc output for /etc/issue from the KV store, keyed by the flow id 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, surfacing it as a task output via the ::{"outputs":...}:: convention.
3. The checkStatus task (io.kestra.plugin.core.flow.If) compares the observed value with the baseline and returns Compliant on a match.
4. On mismatch, the nested doRemediate If checks the remediateControls toggle; when enabled, remediateControl runs sudo chown root:root and sudo chmod u-x,go-wx on the file (following symlinks with readlink -e), otherwise the flow returns Not Compliant.
5. The complianceStatus output coalesces whichever branch executed into a single verdict string for parent flows.

What you get

• A self-contained assess/decide/remediate loop for one CIS control.
• A KV-stored baseline that compliance owners can update without touching the flow.
• Audit-only or auto-fix behavior via a single boolean input.
• A complianceStatus output that aggregates cleanly in fan-out scans.

Who it's for

• Security engineers codifying CIS benchmarks for Linux fleets.
• Compliance teams needing per-control, per-host evidence with logs and timestamps.
• Platform teams standardizing hardening as version-controlled workflows.

Why orchestrate this with Kestra

A shell script can check a file's permissions; it cannot give you per-host execution history, a toggle between audit and enforce modes visible in the UI, secrets kept out of the script body, or composition into a larger scan where any single control can be retried in isolation. Modeling each control as a flow turns a hardening checklist into an operable, observable system.

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-etc-issue-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 the flow for other section 1.6 controls, swapping the target file and commands.
• Orchestrate several controls in parallel from a scan flow using io.kestra.plugin.core.flow.Subflow.
• Record verdicts in a database or SIEM for trend reporting.
• Trigger automatically after VM provisioning with a io.kestra.plugin.core.trigger.Flow trigger.

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