Review both the
ComplianceRemediation object and the
ComplianceCheckResult object that owns the remediation. The
ComplianceCheckResult object contains human-readable descriptions of what the check does and the hardening trying to prevent, as well as other
metadata like the severity and the associated security controls. The
ComplianceRemediation object represents a way to fix the problem described in the
Below is an example of a check and a remediation called
sysctl-net-ipv4-conf-all-accept-redirects. This example is redacted to only show
status and omits
The remediation payload is stored in the
spec.current attribute. The payload can be any Kubernetes object, but because this remediation was produced by a node scan, the remediation payload in the above example is a MachineConfig object. For Platform scans, the remediation payload is often a different kind of an object (for example, a ConfigMap or a Secret), but typically applying that remediation is up to the administrator, because otherwise the Compliance Operator would have required a very broad set of permissions in order to manipulate any generic Kubernetes object. An example of remediating a Platform check is provided later in the text.
To see exactly what the remediation does when applied, the MachineConfig object contents use the Ignition objects for the configuration. Refer to the Ignition specification for further information about the format. In our example,
the spec.config.storage.files.path attribute specifies the file that is being create by this remediation (
/etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf) and the
spec.config.storage.files.contents.source attribute specifies the contents of that file.
The contents of the files are URL-encoded.
Use the following Python script to view the contents:
$ echo "net.ipv4.conf.all.accept_redirects" | python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(''.join(sys.stdin.readlines())))"