This is the first part of a series about the OpenShift Compliance Operator, focusing on installing the operator and running a scan.
Operators are a strong piece of Red Hat’s OpenShift platform, easing the operational complexity of what might otherwise be difficult pieces of the platform. Red Hat’s Compliance Operator provides some relief to the operational complexity of managing the security compliance of a containerization platform. In this blog, I’ll briefly go over installing the Compliance Operator and some of its components. I’ll then show you how to initiate compliance scans, see the results at a high level, and apply the ever-growing number of automated remediations.
The Compliance Operator can be found in the OperatorHub section of the OpenShift console (along with other operators); it installs easily with the default settings by a user with cluster-admin privileges.
The operator install creates an openshift-compliance namespace by default, and once the install completes, you’ll see these tabs on the operator.
The operator provides a nice description of each section, so I won’t go over that here but rather dive right into setting up a scan.
In the ScanSetting section, the operator provides two default configurations.
I’ll discuss those more a little later, but for now, I’ll work with the default configuration ScanSetting, which includes a cron type schedule for running the scans daily, and points to the roles that will be scanned (workers and masters by default). Here’s a partial view of what the YAML file for the default ScanSetting looks like:
For my example here, I don’t need to make any changes to the default ScanSetting.
To initiate a scan, we need to create a ScanSettingBinding. In the ScanSettingBinding tab, simply click on “Create ScanSettingBinding,” and the operator creates a YAML file that defaults to using the rhcos-moderate profile, which will run against the masters and workers. A quick look at the Profiles tab shows all of the different security profiles included with the operator.
I think you’ll find that the Compliance Operator is well documented. For example, if we look into the YAML file of the ocp4-cis profile, we’ll see a good explanation of what this profile includes.
Further down the yaml, it lists all of the rules that it uses:
In the Rules tab, all the included rules are listed, and each of them provides a good explanation of what the rule covers. For my ScanSettingBinding, I’ve added the “ocp4-cis” profile to scan the OpenShift platform as well. Mine (ScanSettingBinding YAML) now looks like this:
As soon as you create and save this binding, the system will initiate a scan. If you look on the ComplianceScan tab. You’ll see the status of each scan normally as either running, aggregating, or done.
Application modernization is a growing area of focus for enterprises. If you’re considering this path to cloud adoption, this guide explores considerations for the best approach – cloud native or legacy migration – and more.
Now that the scan is done, an easy way to view my results at a high level is to run the following command using the OpenShift CLI. First, make sure you’re in the openshift-compliance project:
$ oc project openshift-compliance
$ oc get compliancecheckresult
It will list all the checks and their status (pass, fail, etc.…).
**Note, this is just a sampling. The full list of findings is much longer.
You can get a quick summary by piping this command through a few greps and line counts, as shown below
$ oc get compliancecheckresult | wc -l
$ oc get compliancecheckresult | grep PASS | wc -l
$ oc get compliancecheckresult | grep FAIL | wc -l
$ oc get compliancecheckresult | grep INFO | wc -l
$ oc get compliancecheckresult | grep MANUAL | wc -l
$ oc get compliancecheckresult | grep NOT-APPLICABLE | wc -l
**The first line of the compliancecheckresult output is a header line, so there are 581 checks.
Next, I’ll apply all of the provided automated remediations. First, I have to tell the scan setting binding to apply the automated remediations it has. You can pick specific ones to apply, but in my case, I’m going to have the operator apply everything that it can. As I mentioned earlier, the operator installed two ScanSettings: a default and a default-auto-apply.
My ScanSettingBinding is set to use the default, which only scans. I’m going to edit it and have it use the default-auto-apply option. I do this by editing the “NIST-moderate” ScanSettingBinding I created earlier.
In the YAML file, I simply change the default ScanSetting to “default-auto-apply”:
Now I can re-run my scans, and the operator will apply all the automated remediations. If you remember from our earlier look at the scans, there are actually three separate scans—one for master nodes, one for worker nodes, and one for the OpenShift platform itself.
Probably the easiest way to restart these scans is from the CLI, using these three commands:
- $ oc annotate compliancescans/ocp4-cis compliance.openshift.io/rescan=
- $ oc annotate compliancescans/rhcos4-moderate-master compliance.openshift.io/rescan=
- $ oc annotate compliancescans/rhcos4-moderate-worker compliance.openshift.io/rescan=
Once these scans complete, I can compare the results with my first scan using the “oc get compliancecheckresult” commands I ran earlier. I’ve summarized the results of the before and after scans in the table below:
|1st Scan||Result||2nd Scan||Result|
You can see that the operator fixed a large number of the findings, and the number of automated fixes is growing quickly as the community writes remediations, and they are vetted by Red Hat.
In future blogs, I’ll show you how to generate some nice, formatted OpenSCAP reports and a way to pull the remaining items into a convenient task list, which will help you create a plan for getting to compliance. I’ll also show you how to use machine configs to customize and automate remediations for your clusters.