How to automatically remediate issues using the compliance Operator
by Juan Antonio Osorio Robles
The Compliance Operator is able to automatically remediate some issues that it finds. Let’s look at the following example
--- apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: moderate-rhcos profiles: - apiGroup: compliance.openshift.io/v1alpha1 kind: Profile name: rhcos4-moderate settingsRef: apiGroup: compliance.openshift.io/v1alpha1 kind: ScanSetting name: default-auto-apply
This ScanSettingBinding object will ensure the cluster is scanned with the
rhcos4-moderate profile, and will automatically apply any generated
remediations. This is done because of the
default-auto-apply ScanSetting object,
which by default has the
autoApplyRemediations flag set to
true. This is in
contrast to the
default ScanSetting object which will not auto-apply the
remediations that are generated by the Compliance Operator.
There is more information on ScanSettings in the product documentation:
When effectuating scans, the Compliance Operator always generate ComplianceRemediation objects. These objects, when applied, will fix compliance issues found by the operator. They are only generated after a scan is done executing, and they can be browsed as follows:
oc get -n openshift-compliance complianceremediations
Compliance Remediations can also be applied individually by switching
apply flag in the ComplianceRemediation object’s
spec. For more
information on this, please see the relevant documentation:
If you don’t want the Compliance Operator to always auto-apply the remediations it creates each scan, but instead want to do a one-off bulk application, it’s possible to do so via an annotation:
oc annotate compliancesuites/<suite-name> \ compliance.openshift.io/apply-remediations=
What about GitOps?
There are more advanced use-cases where SREs would prefer to have all of the remediations in Git. This can be very useful for:
Easy auditing: one can force the application of a remediation to go through a standard PR process where other SREs review the configuration before applying it.
Authorization tracking: There will be a trail that shows who approved the changes to the system.
Re-usability: Having all of the remediations in one place can be very handy to simply re-use the repository and apply it to different clusters
For such cases, there is work-in-progress to enable the
plugin to fetch the remediations before applying them and putting them
in a format that’s usable by popular GitOps systems. There is work on-going
to formalize this for both ArgoCD and Hive.
A POC has already merged for ArgoCD, I’ll elaborate more on this on a separate blog post.
Disclaimer: Hive is not a GitOps system, but has constructs that can easily be integrated into such systems such as SyncSets.